jim.shamlin.com

12: Accessibility

Accessibility is extending the usability of the site to people with disabilities.

Unfortunately, it's become a political issue, and those in favor of accessibility have discredited themselves with emotionalism, statistical distortions, and outright lying. The advice they provide is often ambiguous, setting lofty goals about what a site "should" do while providing nothing helpful to actually get it done.

Meanwhile, the businesses that must pay for the sites to be made accessible gain insufficient return o small a number of users to justify the expense, and designers fear that accessibility means being compelled to create less useful sites for the majority of their audience for the sake of accommodating the few with special needs.

The truth is, it can be complicated and it does and to the expense of creating a site, but not by much. Adding "alt" text to an image is not difficult, and most of the things that make sites inaccessible are actually coding errors that will cause it to render improperly on any computer except the designer or developer for whom it looks OK on his workstation.

At yet, it's not an issue that is likely to go away, so Krug advises a few things that can be done right now that should have a major impact on improving accessibility.

Mainly, fix the existing usability defects. Many of the problems that are obstacles to the disabled are obstacles for non-disabled users: they already have to work around these defects and oddities of design, and the experience would be better if they were fixed. And in doing so, the site will become more accessible to the disabled, who are unable to work around them.

Also, download a screen reader to get the sense of how blind users experience your site (or better still, get a few blind users into the lab). The most common accessibility issue is that the content of the site does not render properly when the user employs a screen reader, a piece of software that translates text into voice, and which reads the page top to bottom and left to right. There are a number of things that can be done with page structure that will make it easier for them to scan the page using a reader.

Finally, there's a list of low-hanging fruit, which can often be addressed very easily (though somewhat tediously if you have to refit a lot of existing pages):

Krug reflects on the previous edition of this chapter, in which he said that he hoped this chapter would no longer be necessary "in five years" because developer tools, web browsers, and assistive technologies would have matured to the point that accessibility was a non-issue. But that hasn't happened, and doesn't seem likely.

(EN: This is somewhat ironic, as those who program technologies to assist the disabled have failed to make their solutions capable, and are pushing the work to everyone else to accommodate their failures. It's like an automobile company insisting that taxpayers pay to change the roads because his car is poorly designed. But I'm not hopeful they will get their act together so long as thus far they aren't being held responsible for fixing their own defects.)