Re: WCAG 2.0 and JAWS

The short answer to the question you "should" ask, but not to the one you
*did* ask: Don't design for a version of software, in general. Design for
"accessibility" using techniques like "progressive enhancement" and
"graceful degradation" as much as possible*. The more you learn who your
audience really is, the better you can efficeintly make your design match
their real situation.

The short answer that is bad, but probably not worse than any other: Right
now, assume you have to cater for Windows XP and software that runs on it.

The long version:

This is a common question. And, I think, a reasonable one, although it
doesn't get directly at the heart of the problem. Let me see if the
following makes sense...

> On Tue, 24 Jul 2012, Ryan Jean wrote:
>> [...] In other words, does JAWS 12.0 meet the
>> criteria? 11.0? 10.0? So forth? How far back do we not have to worry
>> about the criteria and assume the user has an "at least" version
>> xx.0? Same question for internet browser? IE9, IE8, IE7.?

On Tue, 24 Jul 2012 18:49:37 +0200, <accessys@smart.net> wrote:

> it should cascade gracefully I would not assume any one has anything  
> more than a basic text browser, and very basic screen reader.

First principle is that "Accessibility" is not a yes/no proposition, in
general. For a specific person, obviously, you can find out whether they
can use a given site. But as Karen noted, that can lead to assuming that
if a blind person you know can successfully interact with the site, it is
"Accessible".

> remember this is a WORLD wide web and in third world countries an old
> apple II might be the latest tech avaliable.

On the other hand, I don't know of a browser that works on an Apple II. I
did a thought experiment of making one for a BBC micro, and decided it
wouldn't work - text-only browsers are bigger programs than those
computers can handle.

So we can assume that *more or less nobody* is trying to use an Apple II
and is frustrated because the screen reader isn't working. (Not quite
nobody, I suspect, because there are web browsing solutions for machines
like that. But computers don't last forever, especially in harsh
conditions, so most computers will be much newer).

> remember except in closed systems the system used MUST be browser  
> neutral, as well as adaptive neutral.

Indeed. To do this in practice, you need a clear idea of what someone who
gets to your URL should be able to do (and why). Unless your budget is
unlimited (or you are spending someone else's money on your friend who is
going crazy with their particular hobby horse) your aim is presumably to
enable this most effectively at the least cost over the lifetime of the
site.

If your site is horribly tedious to use, it will likely not be as good as
if it is a pleasure to use. This is why e.g. visual design aesthetics are
important, as well as visual communication. But if it is very pretty but
impossible to understand, or do anything, you have likewise failed.

>   the person visiting may be using an Unix system with eMACspeak one  
> must never assume any particular piece of equipment or software.   makes  
> it much harder but also makes it more usable.

This is an ideal. There are various practical problems. For example, not
all browsers support Javascript. It can be used to vastly improve
accessibility, but it can be (and often is) used in ways that create more
problems than they solve.

In an ideal world you back every AJAX interaction with a server-side
equivalent. In some cases (e.g. form validation) you're foolish not to do
this, but it is not a zero-cost activity, and when it comes to choosing
between helpful interactivity and description of key images, real budgets
are not infinite. (In that case, I would generally work as if anyone has
javascript support, and spend my resources on describing key images like
instructions - but it is a judgement call and some real people are
probably getting the short end of a real stick whenever you make it - so
get it right).

On the other hand consider drop-down interactions like the suggestions
fields in search boxes. These can potentially seriously confuse people who
don't see them or where they disrupt concentration. Assuming those people
will have high-quality support for ARIA is probably a bad idea. You should
design these things so they don't mess up with "common" old technologies
(again, my personal rule of thumb would be assume that you have users who
have Windows XP. If that is too expensive to deal with, assume the lowest
common denominator of support between Firefox with NVDA, and
IE8+18-month-old JAWS, and accept that you're maginalising people)

In many cases, there is a question of what you are going to do, and what
you are going to rely on the user to do for themselves.

Despite the fact that all modern browsers allow configuration of text,
many websites include buttons to change the text size. This is not bad in
itself, and some people don't know how to use the functionality in their
browser, so without this redundant feature they are stuck. (Don't laugh at
them if you don't know how to take a word document and use the stylesheet
to automatically determine which fields in a database should be populated
for which of the 700 recipients of a mailout that has 4 dimensions of
personalisation - something *relatively* easy in word) And many of the
people who need the function are the ones who don't know that they already
have it.

For over a decade long descriptions of images (to help people identify
them more clearly as the same as some other image they saw, or to
understand in detail what is being shown) have been able to use the
longdesc attribute to avoid filling a page with text longer than this
email. But only in a few browsers by default, although with an extension
this is easy in more or less any modern browser, and has been supported in
software like JAWS for years (even where there is no native support in the
browser). Should you use it anyway?

Ultimately this is a judgement the site developer has to make - nobody
else knows your needs, your audience, and your budget. Any rule of thumb
(like the Windows XP one at the top) is going to be a gross
generalisation, and wrong in many cases. Accessibility experts are people
who can give you more accurate answers for a given case - or can explain
how to solve your problem (i.e. develop your site) in a way that makes the
question more or less unimportant.

But a general answer like Bob's is correct (i.e. not untrue - and my
generalisation isn't so far off) but too broad to be very helpful.

A specific answer would require a lot more knowledge about what you are
trying to do.

I don't recommend the former as a sufficient answer, and I don't have  
enough information to begin to approach the latter.

Cheers

Chaals

-- 
Chaals - standards declaimer

Received on Thursday, 26 July 2012 21:52:38 UTC