These days there’s one tool feature which "separates the men from the boys", as they say: Whether or not the tool tests the DOM of the page or whether it tests the source file as a string.
One critical component to web accessibility to understand is that the page source (what is seen when you "View Source") is not what the user of an assistive technologies experiences. Screen readers, screen magnifiers, voice recognition software and the like are not browsers. A screen reader, for example, identifies and interprets what is being sent to standard output by the browser. When you view a page in your browser, you’re viewing the browser’s implementation of that page’s source. The browser takes the HTML, CSS, images, and JavaScript and creates the user interface by creating system objects from the DOM (Document Object Model).
As a consequence, the first criteria against which any automated testing tool must be measured is this: Does the tool test the DOM? Be careful here, because some vendors will say that they test the DOM, but it is a browser DOM that matters. There’s a difference between "making" a DOM and actually using a headless browser to test the browser DOM. Nearly all modern programming languages have the ability to make a DOM (primarily best suited for processing XML files). Java has jDOM, PHP has a handful of DOM classes in the standard library, and there are similar built in functionalities in JSP, C++ and others. These are not the same as the browser DOM. The true DOM that must be tested is the browser DOM. Essentially this means the tool either resides in the browser as a plug-in or has its own headless browser.
The best way to verify this is to test this page with an automated tool. If that tool shows any errors, it is not testing the DOM and should not be used.
How to use this page
Each of the sections below contain a snippet of code with accessibilty problems. But those accessibility problems have been fixed using jQuery. That's right, I said it. There are no accessibility errors on this page. If your tool finds some, find a new tool. Plain and simple. Have fun!
The examples on this page are intentionally simple to allow anyone with even beginner knowledge of HTML to understand them. Also, let's face it: if a tool can't deal with these simple examples, how will it deal with much more advanced JavaScript? New examples will be added as time & inspiration allow.
Note: There is presently an issue with some examples when viewed in IE9, which will be fixed shortly.
Y U NO alt attributes?!?
The three images below contain what accounts for the majority of accessibility errors (by volume) that are discoverable using automatic tools: alt attribute problems. The first image has no alt, the second image uses a title attribute, and the third image has an alt which is identical to the image's 'src' attribute. So I fixed those mistakes.
Note: Some tools may complain about the alt attributes being the same. I'd argue that since these are the same exact images being used in the same exact context, they require the same exact alt attributes.
Image Button
Image buttons for forms require an informative alt attribute to indicate the action being performed. This button had no alt attribute, so I added one.
onChange sucks
Nothing more awesome than unexpectedly shifting focus elsewhere, right? People on screen readers love them, really they do. But I decided that the onchange event handler was stupid so I removed it. Also, I added a Submit button.
Note: While tools can check for hard-coded event handlers in the HTML, that's often not how events are bound to objects these days.
Pseudo-button
Because some designers don't like the way buttons look, so they decide to design their own. Then developers use onclick event handlers. Forget that noise. I've decided to fix it so it responds to click as well as 'enter' and 'space' just like a real button. Also, proper aria roles and some tabindex for good measure
Non-unique links
Some accessibility best practices call for you to ensure each link is unique. This way they make sense out of context and cannot be confused with one another. What's the antithesis of this? The dreaded "Read More ". link. What? You don't see them? That's because I got rid of them.
Dallas area surveys damage after tornadoes rip through
About 200 homes were destroyed and 650 were damaged by violent tornadoes in northern Texas, an American Red Cross spokeswoman said Wednesday, a day after the storms tore through one of the nation's largest metropolitan areas. Read More
U.S. Coast Guard to sink Japanese boat washed away by tsunami
The U.S. Coast Guard has deployed a ship to sink a fishing trawler that was swept away more than a year ago by the tsunami off the coast of Japan and is now adrift near Alaska. Read More
Upper Big Branch mine to be permanently sealed
The Upper Big Branch coal mine, where 29 people were killed in a blast two years ago Thursday, will be permanently sealed by the summer. Read More
Judge orders psychiatric exam for JetBlue pilot
A JetBlue pilot who had an apparent meltdown aboard a flight last week will undergo a psychiatric evaluation to see whether he was sane during the incident and whether he is competent to stand trial. Read More
Totally Effed Up CSS
Inline CSS is just poor practice, in general. Other CSS related accessibility issues involve poor color contrast and use of absolute units of measure. Luckily the paragraph below doesn't have any of that.
" A typical e-book user read 24 books in the past year, compared with the 15 books reported by typical non-e-book users. "
Implicit Headings
An implicit heading is a piece of text that looks like it is a heading, but isn't given proper heading markup.
E-books spur reading among Americans, survey shows
E-book users tend to read more often than people who read only print material, Pew found. In particular, they read more books. A typical e-book user read 24 books in the past year, compared with the 15 books reported by typical non-e-book users.
Blinking & Scrolling Text
If you open new windows, you're gonna have a bad time
Opening new windows sucks. Everone hates it and yet the goons in marketing still think you have to do it "so people don't lose your site". Whatevs.
Preformatted text.
The preformatted text below would be rendered to screen readers as if it was just a single sentence. It would be much better presented as a properly structured HTML list. Oh wait. It is.
Arts
Arts100
MWF, 8:00-8:50
TTh, 9:00-10:30
Arts101
MWF, 2:00-2:50
Text Direction & Language
Semitic languages are meant to be read right-to-left. Consequently they must be marked as such using the 'dir' attrbute. Additionally, whenever the language of part of the page changes, we need to mark what language that part is in. Luckily, I've done both of these things
عندما يريد العالم أن يتكلّم، فهو يتحدّث بلغة يونيكود. تسجّل الآن لحضور المؤتمر الدولي العاشر ليونيكود