Monday, March 15, 2010 11:00am
Jared Smith, WebAIM
This session presents a wide variety of mistakes, blunders, misconceptions, over-indulgences, intricacies, and generally silly aspects of modern web accessibility. Sometimes the most serious errors are made by well-meaning developers who misunderstand the concepts or take their limited accessibility knowledge to an extreme level – thus web accessibility gone wild.
“Mistakes, misconceptions, over-indulgences, minutia, and generally silly aspects of modern web accessibility” …or “how to Fail at web accessibility”
The mythical “accessible” web site does not exist. Accessibility is a continuum with many different paths.
Web accessibility is about more than just blindness. We need to think beyond blindness and visual disabilities and look into the cognitive areas which include many more people than those with visual impairments.
Accessible sites don’t need to be ugly. You want a really good experience still, and that’s possible. For people with disabilities the web is a godsend since it allows people with disabilities to access things they normally wouldn’t. Most areas of accessibility calls for larger fonts, contrasting colors, etc. which help everyone and not just those with disabilities.
Web accessibility has a branding issue, and it has devolved into specifications, checklists, and techniques. People run through a checklist of what they think is accessible, and just leave it at that. Web Accessibility is a continium and needs to be addressed again and again.
Compliance does not necessarily make your website accessible. Use guidelines as tools (and only tools) to achieve accessibility. So, your site can be fully compliant, yet totally inaccessible. Your site can also be fully compliant and technically accessible, yet functionally inaccessible.
Can you have too much accessibility? Yes! Web accessibility can and should happen naturally.
Accessibility implemented partially or incorrectly can be worse than no accessibility at all. Basically you need to build one version of a web site that is fully accessible. If there is a page you cannot make accessible then you’ll need to write alternative text to it.
This is probably the most difficult aspect of Web Accessibility. You cannot define in a spec what equivilant
Alternative text for images should contain Content and Function. If you have a photo of yourself, you should probably have the “alt” tag set as your name, or “Photo of [your name].” If you have a graphical bullet, then don’t make it alt=”bullet,” that’s just bad all over. Also, having “image of…” or “graphic of…” in alt text is bad. It just becomes redundant, and you don’t want redundancy. However, if it’s an Illustration or a Photo then perhaps “Photo of…” or “Illustration of…” could be appropriate. But this is not necessary everywhere.
Do focus on content and functionality. “I don’t want to miss out on any content” vs. “I’m listening to the page at 400 words per minute in a robotic voice and I don’t want to miss out on any content.”
I’mages that are the only thing within a link, then this must have alt text. Otherwise the screen-reader wont know how to read off what the link goes to. In most cases if an alt tag is missing, it will read off the file of the image, or the URL it goes to. Avoid redundant text in cases where you have an alt tag assigned, but next to the image is the same exact text. It’s perfectly accessible to make the alt tag of an image blank in this case.
Captcha for spam prevention will not be accessible for people unless there is an audio version. And if someone is both deaf and blind then neither of these visual or audio preventions will work.
Accesskey and Tabindex is usually fail unless you’re sure you know what you’re doing. Learn the power of tabindex=”0″ and tabindex=”-1″.
- tabindex=”1+”: Specifies exact tab order. Ensure tab order is complete, logical, and intuitive. Rarely needed.
- tabindex=”0″: Places element in the default tab order.
- tabindex=”-1″: Do not place element in tab order, but allow the element to programmatically receive focus.
Tabindex, focus(), and Aria to the rescue! Aria stands for “accessible rich internet applications.” Accessibility will greatly be built into HTML5.
- Gives or enhances semantics of non-semantic or other-semantic elements
- Landmark roles – define major functional areas of your page (search, navigation, main, etc.)
- Enhances keyboard accessibility for widgets and controls
- Ensures accessibility of dynamically updated content
Visually hiding content
- Display:none and visibility:hidden hide from everyone… and that’s a good thing.
- Absolute position off-screen left with CSS for screen readers
- Use judiciously
The native accessibility (and usability) of your site is typically inversely proportional to the volume of …___
Make sure to skip to the main content links. Until browsers provide better keyboard navigation for sighted users. You can position them off-screen if you must, but make them clearly visible on :focus. One “skip” link is typically sufficient.
Do not removing focus indicators from links with the CSS attribute outline:0. CNN.com uses this, so when you tab through links you have no idea where you are. That’s a bad CNN, bad!
Bullet-proof web design is good. It’s a way for a designer to understand that they do not have control over what the website looks like to the end user. For example, if someone increases the font size then it shouldn’t make the website look crazy with the design.
Avoid links which say, “click here” as they lack description.
Headings; h1, h2, etc.; are great as screen readers (such as Jaws 10) will navigate you to these as “content” chunks. Lists are also very useful for navigation in design, and very very important in accessibility.
Odds and Ends
- Test in a screen reader. NVDA is an open-source and free
- Provide accurate, descriptive, succinct page titles
- Don’t stress over screen reader pronunciation and quirks.
- Expand first instance of acronyms and abbreviations. You don’t have to use <acronym>/<abbr> on all instances. Don’t use for well known terms.
- Use <fieldset> and <legend> for groups of radio buttons and checkboxes.
- Layout tables don’t (typically) affect accessibility.