WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.0 'accessibility supported'

for

From: Randall Pope
Date: Feb 6, 2009 8:15AM

Not to mention the assistive technology is not keeping with the latest web
design and its application. The reason behind this is of course little
money for research and development of new products.

With Warm Regards,
Randall "Randy" Pope
American Association of the Deaf-Blind
Website: http://www.aadb.org

301 495-4402 VP/TTY
301 495-4403 Voice
301 495-4404 Fax
AIM: RandyAADB

Want to keep up with the latest news in the Deaf-Blind Community? Consider
subscribing to the monthly newsletter, "AADB Today" at http://aadb.org. It's
free and AADB membership is not required.

-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Steve Green
Sent: Friday, February 06, 2009 7:56 AM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] WCAG 2.0 'accessibility supported'

This is one of a number of areas where WCAG 2.0 has introduced ambiguity
where issues were clear in version 1.0. The issue of accessibility supported
technologies is now untestable, which is precisely the opposite of what the
W3C intended.

Th W3C acknowledge that there is a high degree of ambiguity in their
explanatory notes at
http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-
support-head and 'welcome discussion' even though it won't change anything.

Strictly speaking, Patrick is correct when he says "there are widely
available user agents that support resizing". However, 75% or so of Internet
users do not have such user agents. Furthermore, they have no way of knowing
that using a different user agent would allow the text to be resized. This
is a very different scenario from being prompted to install a plug-in that
you currently do not have.

I disagree with Patrick on the final point. To quote from the WCAG 2.0
explanatory notes,
"The way that the Web content technology is used must be supported by users'
assistive technology...
AND
The Web content technology must have accessibility-supported user agents
that are available to users"

In my opinion WCAG 2.0 is misconceived, badly written and will result in a
reduction in website accessibility. We all know that using pixel values for
fonts reduces accessibility. We all know that using PDFs reduces
accessibility. The fact that WCAG 2.0 says these techniques are ok doesn't
mean you're making an accessible website. It just means you are compliant
with a bad set of guidelines.

If you care about accessibility, do the right things (you know what they
are). If you just want the badge, take a literal interpretation of WCAG 2.0.

Steve



-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Patrick Lauke
Sent: 06 February 2009 11:35
To: WebAIM Discussion List
Subject: Re: [WebAIM] WCAG 2.0 'accessibility supported'

Here's my interpretation of it:

> Mark Magennis

> 1. Does the fact that many users use IE6 (with its default settings)
mean that the use of pixel values in HTML is not
> accessibility supported? And if all users switch to using a browser
that can resize text specified in pixels, would that
> mean the use of pixel values is now accessibility supported?

I'd say that yes, pixel values are ok because there are widely available
user agents that support resizing.

> 2. If the HTML page was removed and the same plain text sentence was
presented in a PDF file such that it could be resized
> by all user agents that display PDFs, would that use of PDF be
accessibility supported?

If the PDF was accessible in itself, yes.

> 3. Does this mean that whatever technology is used (HTML, PDF or
whatever), it is not the technology itself that is either
> accessibility supported or not, but the way that technology is used or
the specific functionalities of the technology
> that are used?

The former: it's a technology that is accessibility-supported (or, to be
more specific, the particular aspect of the technology that's used is
accessibility-supported - the technology as a whole may have parts that are
not supported, but you as an author only use the bit that is indeed
accessibility-supported).

P