The GW Micro blog has been discontinued. For instant updates on GW Micro products and events, follow us on Twitter, and like us on Facebook.
Advocacy On and Off the Clock
by Aaron Smith on Friday, October 8 2010In the adaptive technology field, you're constantly reminded of accessibility barriers even when you're not working. One of our developers recently encountered a local library website whose menu links would disappear if the page was zoomed in (a common practice of low vision users, and people who don't want to squint to see small print). Their solution? Just zoom out. Ignorant suggestions and "solutions" like this are thrown around all the time without any consideration to the affected end users. It was enough to prompt the following response from our developer:
Okay, I know my previous comment was a bit flippant, but seriously: this stuff is important. This kind of inattention to the accessibility needs of your patrons is the kind of thing that gets you sued by advocacy groups. You wouldn't tell an older patron in the library to just suck it up and read the non-large-print version of the latest potboiler, so why do you think that's an acceptable workaround on the web? There's a simple rule of thumb that professional web designers all learned years ago, and that whoever wrote the stylesheets for this new page doesn't seem to have learned: if any measurements in your stylesheet are given in pixels, and they're not intimately tied to the size of a raster image, your stylesheet is broken and won't work for some fraction of your web visitors. If you want this site to be accessible to mobile users, or to users with vision impairments (which is going to be most of the population, as the Baby Boom generation continues to age) or to users with other special needs, you need to account for the fact that their browser settings will not be the ones your browser defaults to, and you need to test, then test some more, then test even more until you've eliminated all possible sources of bias. Here are some other things to test: - how does your page look if my browser window is maximized, but my monitor is rotated to portrait view? - how does your page look on an iPhone? - how does your page look on a cellphone that's not an iPhone? - how does your page look if I have my Windows color scheme set to high contrast? - how does your page look if I'm using large fonts? - how does your page look if I have a high-DPI monitor? - how does your page look if my browser window isn't maximized? Ideally, I shouldn't have to scroll to see the important bits. - how does your page work on Internet Explorer, Firefox, Chrome, and Opera? How about on Linux, Macintosh, BSD, and Windows? - how does your page work if I have my browser set to use a personal stylesheet to deal with some visual impairment or other? These are questions you should have answers to before you deploy. You should not be scrambling to answer them while your patrons are trying – and failing – to use your website. I know this is probably not your fault. You probably bought this interface from XYZ, and they have never been known for their ability to create a usable user interface. But it's your reputation on the line, not theirs. It's your front-line staff who now have to do things for me because this website works so poorly now. (I'm a computer professional, with 15 years of web design experience and 25 years of application programming experience. I can't begin to imagine how badly this thing works for your grandmother.) And it's your already-dwindling budget that has to pay those people who are picking up the slack for this half-baked design.
