Presentations: Head Conference: Speaker Notes
First Principles of Web Accessibility
Social vs Technology
Web accessibility is not a problem about technology, it's a social and civil rights issue. It's about protecting the rights of disabled people to participate in the online community, not locking them out of an environment that offers them independence. We use technology to remove or work around barriers that prevent people with disabilities from participating on the web. We use technology to solve social issues and protect civil rights.
It turns out with a good understanding of the barriers and issues faced by disabled people on the web, the technological solution in most cases remains relatively straight-forward. As we move to rich hypermedia, like live video and audio, do accessibility solutions become more complicated.
Notes
- Target Corporation were taken to court by the National Federation for the Blind, on behalf of Bruce Sexton, because of their inaccessible website. After working with the NFB and then refusing to make the requested changes, this incurred three years of lawyer fees in defending the action in courts, and ended in a settlement where Target voluntarily paid the plaintiffs of the class action a sum of $6 million.
- The effort Target went through utterly dwarfed the actual repairs they needed to make. Most of Target's problems could be fixed by including text-equivalents where images were used to provide content or process cues.
Beware of the techno-babble
One of the dangers of web accessibility is when developers don't pay enough attention to actual people, their actual disabilities and the actual barriers that are presented to them. But instead people focus too heavily on the technical 'requirements', where those requirements do not have a solid basis in understanding the nature of disabilities.
What ends up happening is a distortion of what web accessibility is from creating websites that are accessible to people with disabilities to something along the lines of creating content that is unambigiously parseable by machines. By taking disability out of the picture, the fundamental premise of web accessibility is ignored, and a different problem is solved - just not the one that's needed to be solved.
Beware the false analogy
Technology writers struggle to understand web accessibility, and they paint it as some horrible process that eats away at the souls of talented engineers. Because their understanding of web development is so superficial, they reach into other seemingly analogous areas to substantiate their understanding.
The most common is to point out that news papers don't have a large print version or braille version, so why should websites have to be accessible. Apart from that being flatly untrue - you can order large print, braille and audio versions of newspapers. And yet, making the similar content accessible on the web is far easier - and takes less time than finding these spurious arguments.
David Berlind on Target
When the National Federation of the Blind launched legal action against Target Corporation for an inaccessible website, David Berlind defended Target pleading on behalf of the poor web developers not to impose such evil tasks. Berlind tries to make the case against such horrific practices by providing example after example of the burdensome tasks, and mangles it badly. And then came the piece de resistance:
"I was in Cambridge this morning and saw Dan Gillmor. When I told him about the story, he asked if all the items sold in physical stores are marked with Braille. Precedent set."
Again, this isn't strictly true. In my own limited experience, some wine producers label their wines in braille. The range of goods labelled in braille is growing. And yet, these practices are far far more difficult than repairing the accessibility barriers on the Target website.
Target only needed to do five things to fix the major accessibility problems for screen reader users:
- For Active Images - Where a link just wraps an image (be it an inline image, a CSS background, or an image map) - insert a text-equivalent of the image at the same point.
- Make sure every button or call-to-action is accessible via a keyboard. This boils down to using only links, or form buttons for these widgets, not onclick events on non-focusable elements, nor using mouse specific event handlers like onmousedown.
- Provide text-equivalents for images used as content (when that text-equivalent isn't already present nearby).
- Skip navigation links - only because there are so many of them, 50 consecutive tabs to get past them.
- Label form fields to facilitate in identifying what information a visitor needs to enter
Those changes should not cost $6 million. If they did, then Target has a much larger problem than just a web accessibility one.
Notes
- Joe Clark's commentary
- Between the Lines: Why a landmark court case could force you to redo your whole Web site
Microformats - the date-time abbr pattern
The Microformats community fell into this hole early on with Tantek's ephiphany that a colloquial date and time reference was an abbreviation of an ISO timestamp. And so, date-time references were marked up as attributes, and the title attribute that is supposed to contain the expanded form of the abbreviation, with the idea that the expansion clarifies and makes more understandable.
Microformats: Tantek's quote that the date-time pattern is accessible because it can be transformed into a variety of different date formats. Data-wise, the information is manipulatable, but only if you are using tools to manipulate it.
- I get most frustrated when the ISO date time format is referred to as 'gibberish' when in fact it's quite the opposite.
- The irony of the whole thing is that the ISO format is the most accessible way of publishing date information that I can think of.
- It's international and completely unambiguous.
- Yet people shy away from publishing it in the name of 'accessibility'.
- The accessibility of dates is a distraction, caused from machine data that shouldn't have been exposed to users in the first place.
Unfortunately, microformats has the design principle that data is not hidden from the visitor, which means that machine data - or human unfriendly data - is inserted in the document to an extent that it gets in the way of visitors. This principle has repeatedly been stated as invioble, and that conflicts with the accessibility principle of ensuring content is human readable and understandable.
- Drew: "BenWard: the converse is that we hide things, which is against a core design principal"
- we must not go down the path of invisible (meta)data - IMHO that principle is inviolable for microformats
- in fact, given that it is "not visible data", I think perhaps a better way of putting it is "dark data"
- the problem is that the full datetime is not the most readable
- people can understand/read 2008-06-24 quite easily
- it's when you introduce the T and the time that it looks ugly becomes quickly unreadable
- it is the compound datetime that is the problem
Not true. Its the sequence of numbers with no obvious connotation that is the problem. It's also a problem from a semantic perspective. Using the abbr element in particular means, that when abbreviations are expanded - so when an abbreviation is replaced by the expanded form, in this context, a human readable date is replaced by machine data. The end result is something less readable and less understandable - and that really goes against the purpose of the abbr which is to facilitate understanding of abbreviations, acronyms and initialisms.
Screen reader example
2008-10-20 14:52:25 +05:00 with Window-Eyes 7: "two zero zero eight one zero two zero fourteen fifty twenty-two five o'clock" IE with Jaws 10 beta: "two thousand eight dash ten dash twenty fourteen fifty twenty-two plus five o'clock"
Splitting the date, time and timezone into separate components doesn't help either, for example:
<abbr title="2008-10-20">Monday, 20th November</abbr>, <abbr title="14:52:25">just before three o'clock</abbr> <abbr title="+05:00">local time</abbr>
This still reads out as: 2008-10-20, 14:52:25 +05:00 with Window-Eyes 7: "two zero zero eight one zero two zero fourteen fifty twenty-two five o'clock" IE with Jaws 10 beta: "two thousand eight dash ten dash twenty fourteen fifty twenty-two plus five o'clock"
I'm baffled how this is more readable or understandable than: Monday, 20th November, just before three o'clock local time
abbr conclusion
The key takeaway from this is that the abbr element must not be used for machine readable data that is not human friendly. If the title of the abbr should make its abbreviation more understandable to a human being, that includes people using screen readers.
Holistic view of accessibility
Accessibility is a layered problem, but it is based on a simple premise: producing content that is accessible to people despite their disability.
- People
- Assistive technology
- Operating System
- Browser
- Web Content
Computers are complicated contraptions. We understand them by simplifying our perception of them. When we think of people browsing the web we think of something called web content and we think of the person looking at that web content.
Web content ---> Person
With this simple model in mind we could say that if the web content was accessible, if the person represented here is disabled, then the content would be accessible to that person because the web content was accessible in the first place.
But things are not as simple as that. Yes, for web content to be accessible to a disabled person, it needs to be accessible itself: it seems rather obvious to the extent that logic itself is redundant: Accessible content has to be accessible. It is a good starter, but not enough. We can have perfectly accessible content that isn't accessible to someone with a disability.
Web content is rendered to the person via a computer. And that complicated beast is made up of a multitude of layers. We need a model of a computer that is more sophisticated than a single arrow between Web content and a person, one that better explains the various pieces of a computer that allows content to be accessible to a disabled person.
Web content -> browser -> operating system -> assistive technology -> person
Between each of these components there's an interface, be it either raw data, or program logic.
Web content is a nebulous conception. On the whole we think of it as HTML, CSS and JavaScript. Perhaps it is Flash, or PDF, or an MP3, or a JPEG. It is web content merely because it sits on the web.
A browser is a piece of software that takes web content and aids in the rendering of that content. It is nothing more than a helper application.
The operating system is a massive chunk of code that really does all the interesting stuff. Typical operating systems like Microsoft Windows and Apple's OS-X offer us hooks into widgets. These widgets are, for example, a button, a checkbox, a piece of text, an editable text field, a menu, a window frame, a window pane. They exist as both logical entities as well as physical perceivable entities.
The operating system has the logical concept of a button, which is a widget that has states like pressed and not pressed; focused or not focused; active or not active; as well as behaviour like "Call this piece of code if the button is clicked by a mouse, or activated by keyboard control". It also has properties like a text label (or perhaps a rich text label, to allow images to appear on a button - like icons).
The modern operating system also typically deals with the visual rendering of a button. The GUI is nothing more than a visual representation of a set of logical widgets on a screen that can be interacted with. But that's not the only rendering of a widget that's available.
The logical representation of a Graphical User Interface can be rendered aurally - people can interact with it using a mouse, or a keyboard, or voice, even a straw, or various combinations of these, and each important interaction results in a change within the logical model of the user interface, which results in an updated representation of the user interface on a screen, or aurally.
The significant point is that because there is a logical model of a user interface, that can expose information in senses other than sight. We can interact with this model with a diverse range of devices, not just a mouse. The flexibility allows the owner of the computer to select the most appropriate interaction combination that best meets his circumstances.
Because the operating system has a logical model, this pure data can be exposed to other interfaces. The predominant one for accessibility is the Accessibility Architecture layer, and on Windows we have a Microsoft Accessibility Architecture (MSAA). This is a programmatic interface that can be listened to for logical events (like a button called Submit has been clicked). It also provides access to the logical data models that make up the information contained in an application, so for a web browser, MSAA provides read access to the logical data structure that makes up the web content being rendered.
That MSAA layer allows a rich set of asssitive technology tools too hook into the operating system and provide access to the logical view of data. So a screen reader queries and listens to the various messages coming through the MSAA layer, and allows the owner to navigate through the user interface by conversing with the owner. The screen reader is a complicated and rather powerful piece of software that provides a talking interface on top of an operating system. It also captures keyboard activity and uses that as a means of interacting with the talking part of the interface, or passing those keyboard strokes back to the operating system, which passed that back in some form to the actual browser.
- Talk about text sizing/colour contrast as an operating system configuration
- Talk about assistive technology that sits in the operating system (screen magnifier), and browser.
- Talk about zoom layouts - a webcontent/browser based assistive technology
- Rendering to touch - refreshable braille display
For content to be accessible, each component of our computer stack needs to ensure that it does not create a barrier to the web content. So it means that for content to be accessible, the web content itself has to be accessible, the browser needs to talk properly with the operating system, and to the accessibility architecture properly, and that any assitive technology properly interacts with the accessibility architecure. A failing of one single component can mean that the web content, however well developed, will be inaccessible to the user.
The web developer alone cannot be held responsible for his content not being accessible. But he has the responsibility to author the content to the best of his ability, to make it as accessible as possible, but he also needs to be able to trust that the other components - the browser, the operating system and the assitive technology are doing their jobs properly. None of these components alone can make content accessible, it requires the collaboration and trust of each component to do their jobs properly.
Responsibilities of each component
- Talk about the fundamental basis of Joe Clark's "When Accessibility is not your problem"
cover text resizing, text-to-speech,
- Talk about how ARIA is a simulation of exisiting logical widgets and is an extension to the browser so web content can access it
- Talk about the abbr in IE6 being switched on by document.innerHTML - document.innerHTML
The POUR Principles of Web Accessibility
Perceivable
Content must be perceivable by people with disabilities. So information and user interface components must be presented in a way they can perceive. For example:
- can a blind person hear the content via their screen reader,
- can a blind person feel it through a refreshable braille display
- can a colourblind person see the content.
- can a deaf person see the content on screen?
The invisible link
<a style="background-image: url(/logo.gif);" href="/"></a>
This is a link that isn't perceivable by a screen reader user, nor a refreshable braille display user because there is no text label for the link. The link is actually an empty container with a height and width specified in an external stylesheet, and the background image contains the actual content.
This problem can be rectified in several manners:
- a title attribute on the anchor
- text between the tags which can be styled to appear offscreen - so using Image Replacement
- Use an image inside the a tags instead of the CSS background, and use the alt attribute of the image to supply the proper text-equivalent.
Hover effects
Some sites show and hide buttons when a mouse is over a certain area of the page. When Yahoo Buzz first launched, you could only get the "Thumbs down" button when you hovered over a story.
The button itself was marked-up correctly, using a focusable element like an anchor. But it was inside a container that only appeared when a mouse-only event was triggered. So keyboard users could not reach this particular button. The fix here is more complicated - it's actually a design issue or a user-interaction issue. The first step would be to sit down with the interaction designer and demonstrate the problem. The solution is either:
- use mouse-independent event-handlers in conjunction with onmouseover
- encourage the interaction designer to come up with a better more usable interaction - since it is mysterymeat navigation after all
- get the user interaction designer to define a different interaction manner that doesn't depend on mouse movement, and then recode using the accessible method, and add back the onmouseover as a progressive enhancement.
Operable
Once a user-interface element is perceivable a visitor will know it is there. It is now important for a visitor to be able to interact with that user interface element. So if the call-to-action of a button is perceivable, the visitor must be able to trigger it.
Typical operability barriers include:
- Not being able to activate a button
- making a button inactive after a short period of time.
- Flickering or moving elements on a page
- Not being able to jump past focusable element(s)
Yahoo OpenId's impossible call-to-action
Yahoo's first beta version of the OpenID website explains to non-geeks what open Id is in friendly terms. One of the features they offered was a "Take a tour", which was a slide show that explained step-by-step the benefits of using OpenId.
Being a slide-show, the interaction required JavaScript. So the natural reaction was to add a "Take the tour" button using JavaScript, so that when JavaScript wasn't available there wouldn't be a broken link. However, the markup inserted into the page was something like this:
<span id="tourlink">Take the tour</span>
and in the JavaScript section:
YAHOO.util.addEvent('tourlink', YAHOO.openId.takeTour());
This user interface element is perceivable (barring any CSS rules to the contrary). Can be clicked on using a mouse. But it cannot be focused by keyboard, which means the user cannot trigger the onclick either.
At the time I reported this error I was puzzled why a span was being used for what obviously looked like a link. A few weeks ago I stumbled across a Frontend Engineer Best Practice Guide (for some reason Web Developers are called Frontend Engineers in the US. Bizarre but true). This guide stipulated that javascript only links should not be added to the page, because the link wouldn't work when JavaScript was disabled.
In our example, when JavaScript is not available, we see the call to action, but not marked up as a link. It's still broken, just not as broken if the developer used a link instead. When visitors see a call to action, they expect it to be clickable. Failing that they expect to see a user interface element nearby that they can click. But seeing neither, they realise something is broken, regardless of whether there is no link present - they expect to have one.
The solution here revolves around what needs to happen when JavaScript was not available. In our case here, they wanted the slideshow to work as separate static pages, so the solution became:
<a href="tour_1.html" id="tourlink">Take the tour</a>
and the link worked using keyboard access regardless of whether JavaScript was enabled or not, and the mouse users saw no difference.
Understandable
Now that we know a visitor can perceive and operable a particular user-interface element, we need to make sure that the element is understandable.
Yahoo's non-intuitive streaming quotes toggle switch
The text of a link should typically indicate the destination or action that will be performed when that link is activated. When a link says "On", the expectation when you click it is to turn something on. When a link says "Off", the expectation is when you click this link, it will turn something on. Unfortunately, the Finance streaming quotes does the exact opposite - the link text is the current status of the feature before it is activated.
This is a known usability problem -- A toggle button, which goes against usability of buttons being verbs, not state.
Hiding error messages until they are needed
display: none on validation messages, so that when an error does occur, the message is made visible.
Machine data in plain sight
- Microformats
- Finance JSON object
Robust
Yahoo's non-robust Music site
JavaScript heavy Music, with JavaScript disabled showed a purple background, 3 adverts, and zero content.
Failing graceful degradation. Progessive enhancement is the web accessibility safety net. If a higher level creates a barrier, then it can be switched off without compromising core functionality.
Personal Thanks
- Joe Clark
- Jim Thatcher
- Benjamin Hawkes-Lewis
- Jon Gibbins (dotjay)
- WCAG 2.0