WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.0 'accessibility supported'

for

From: Benjamin Hawkes-Lewis
Date: Feb 7, 2009 2:25AM

On 6/2/09 15:06, Steve Green wrote:
> Real users just take what they see at face value. If they can't resize the
> text with their browser then they assume it can't be resized. If their
> browser lacks a feature, they don't go looking for another browser that
> might have it because most people assume there is no difference between
> them. And life's too short for what may turn out to be a fruitless search.

Okay, I suspect this is a "two camps" area of disagreement:

http://www.thepickards.co.uk/index.php/200609/the-usefulness-of-accessibility-audits/

http://accessites.org/site/2006/10/the-great-accessibility-camp-out/

http://www.isolani.co.uk/blog/access/BarCampLondon2AccessibilityPanelThoughts

http://joeclark.org/appearances/atmedia2007/

I think it's a mistake to conflate disinterest with disability, and
backwards compatibility with web accessibility. Catering to users who
just aren't that bothered and supporting older or alternative user
agents can be worthy goals, but it's useful to distinguish those aims
from ensuring sites are accessible to people with disabilities. Some
reasons for that:

* Making sites accessible to people with disabilities carries a greater
moral weight than the other two goals.

* Companies often have legal obligations to make sites accessible to
people with disabilities. It confuses the issue if we justify backwards
compatibility adjustments as though they were addressing those legal
obligations. (IANAL and I do admit the possibility that a court or
legislature could decide backwards compatibility is an essential
component of making sites accessible to people with disabilities, though
it seems unlikely to me.)

* "Google is blind" may be a good slogan when selling accessibility to
businesses, but it gets problematic if developers buy it wholesale. It's
important to be able to be able to prioritize these goals as they
sometimes conflict. For example, optimizing for people trying to find
content via search engine user agents can conflict with helping people
trying to consume content with screen readers in areas like text
equivalents, hidden text, heading choice, and source order.

* Packaging all three goals together can become a disincentive to
meeting any of the goals ("My Web 2.0 application doesn't work in IE6 or
Lynx or JAWS 4, so it can't be accessible, so I won't bother with alt
tags" or "My photo sharing site doesn't cater to blind people, so why
bother with web standards", etc.).

* Laying all three requirements at the feet of website developers
absolves users and user agent developers of their own responsibilities
in a way that is ultimately self-defeating. User and user agent
developers need to come to the table too:

http://www.w3.org/WAI/intro/components.php

Just last month, we had a thread on here with folks arguing that every
page should have a text resize widget because people don't know how to
use the Text Resize or Zoom commands on their browser:

http://www.webaim.org/discussion/mail_message.php?id=12287

http://www.webaim.org/discussion/mail_message.php?id=12291

http://www.webaim.org/discussion/mail_message.php?id=12294

Indeed, as you say in another message in this thread of the Text Resize
feature: "I have never met a single person outside the development
community who knew that text resizing is possible, far less how to do
it. I'm sure there are some, but they are extremely rare."

It seems to me if you take your logic of catering to users who aren't
willing to investigate how to improve their web experience seriously,
using px is irrelevant as you need to provide a text resize widget anyway.

I think the end result is a poor user experience, where every page is
crowded with omnipresent functionality that should be in user agents -
text resize widgets, skin selectors, text-to-speech, clocks, translation
and definition tools, print buttons - all implemented differently on the
sites that are willing to do so.

> Zoom serves a different purpose and is not a suitable alternative for text
> resizing in my opinion.

Why? Are you concerned about horizontal scroll? Do the fit-to-width
reflow capabilities of Opera and IE8 allay those concerns at all?

--
Benjamin Hawkes-Lewis