simple accessibility test
ForumAccessibility on LibraryThing
Melde dich bei LibraryThing an, um Nachrichten zu schreiben.
Dieses Thema ruht momentan. Die letzte Nachricht liegt mehr als 90 Tage zurück. Du kannst es wieder aufgreifen, indem du eine neue Antwort schreibst.
1jadelennox
I have seen Tim express the belief that accessibility is too difficult because accessibility standards are huge (true), vague (unfortunately and necessarily true), and difficult to validate to (true because of the first two points). Yesterday at work, when I pointed out that one page on our work website was completely inaccessible because all the navigation was via image map, a coworker said "yes, but the replacement is also inaccessible" -- by which I finally realized that she meant "doesn't pass validation tests". Which made me realize that my coworker, like many other people (possibly including Tim) , sees accessibility as somewhat all or nothing. If you can't past validation tests then you just aren't accessible.
So here are three great and simple tests to see if a site can be accessible for *most* users with accessibility needs. These three tests will not catch the long tail, but they will catch a whole lot of people with disabilities, and passing them will make your site much more accessible. They are all very easy to code to. And LibraryThing does not pass two of these three tests -- and could, pretty easily. If LibraryThing webpage programmers run all of these tests on each page before they make it live, the site will suddenly become much more accessible.
1. Turn off CSS, and see if you can get to all of the page's content. This will reveal if information which is usually hidden and revealed via JavaScript (e.g. drop-down menus, values which are hidden until an expansion box is clicked, etc.) are fully available to screen readers. (This is easy in Opera and Firefox, but I'm not sure about Internet Explorer. In Firefox, go to View, Page Style, No Style.)
2. Turn off JavaScript, and see if you can get to all of the page's content and features. (In Firefox, use the NoScript extension for easy management of this -- http://noscript.net/ )
3. Turn off images, and see if you can get to all of the page's content and features which can be made meaningful without images. For example, choosing the appropriate cover image might not be important, but being able to find an RSS feed is. (In Firefox, the best way I know to do this is via the accessibility extension -- http://firefox.cita.uiuc.edu/ -- but there might be a better way.)
That's it. That's it. Forget, for now, about validators which paste red marks all over your website and tell you that nothing will work. If you can access the content and features of your website in some way, no matter how much of a pain in the butt, with images, JavaScript, and CSS turned off, then you have gotten the lion's share of people with accessibility problems. Do that, and you can worry about the Long tail later.
So here are three great and simple tests to see if a site can be accessible for *most* users with accessibility needs. These three tests will not catch the long tail, but they will catch a whole lot of people with disabilities, and passing them will make your site much more accessible. They are all very easy to code to. And LibraryThing does not pass two of these three tests -- and could, pretty easily. If LibraryThing webpage programmers run all of these tests on each page before they make it live, the site will suddenly become much more accessible.
1. Turn off CSS, and see if you can get to all of the page's content. This will reveal if information which is usually hidden and revealed via JavaScript (e.g. drop-down menus, values which are hidden until an expansion box is clicked, etc.) are fully available to screen readers. (This is easy in Opera and Firefox, but I'm not sure about Internet Explorer. In Firefox, go to View, Page Style, No Style.)
2. Turn off JavaScript, and see if you can get to all of the page's content and features. (In Firefox, use the NoScript extension for easy management of this -- http://noscript.net/ )
3. Turn off images, and see if you can get to all of the page's content and features which can be made meaningful without images. For example, choosing the appropriate cover image might not be important, but being able to find an RSS feed is. (In Firefox, the best way I know to do this is via the accessibility extension -- http://firefox.cita.uiuc.edu/ -- but there might be a better way.)
That's it. That's it. Forget, for now, about validators which paste red marks all over your website and tell you that nothing will work. If you can access the content and features of your website in some way, no matter how much of a pain in the butt, with images, JavaScript, and CSS turned off, then you have gotten the lion's share of people with accessibility problems. Do that, and you can worry about the Long tail later.
