WAI - Your opinion - Do you design accessible sites?

On Fri, 14 Jan 2005 nichughes (AT) mailandnews (DOT) com wrote:

In as much as the web page or service is capable of being reached
then it is accessible.

Just so, but you have to interpret that in its context.

That does not appear to be the problem here.

Oh, I think it is, in the overall business process sense. Getting
access to the web page is not the real issue here - this web page is
not an "end in itself", but exists as a means to access a service.
Unless that service can be effectively utilised via the web page, the
*service* is inaccessible - no matter that the *web page* itself might
be the most accessible page on the whole web.

In this example there was no step of the process that the person was
unable to complete, the issue was that completion took longer for a
blind person and therefore failed to meet a time constraint. Every
single accessibility guideline could be followed to the letter and
still hit this problem.

On a practical basis the only way you are going to identify and rectify
issues of this sort is through the disciplines of usability analysis
and testing. This is an established field of computer science that has
a whole toolkit of methods to deal with exactly this sort of issue.
Accessibility tools on the other hand are demonstrably not going to do
the job - because every single part of the process is already
accessible.

I simply do not see how it is helpful to regard this as an
accessibility issue - unless you have simply chosen to redefine the
word for your own personal use to mean something far more than it does
to most people. There really is nothing wrong with the existing
definitions of these terms. The only trap here is for people who are
not usability practitioners to think that usability is only about
"average" users. Real usability analysis is far more involved than that
and requires an understanding of the various sub-sets of the intended
user base - including those using the system under unusual
circumstances or with particular needs.

--
Nic

"NicHughes" <nichughes (AT) mailandnews (DOT) com> writes:

In this example there was no step of the process that the person was
unable to complete, the issue was that completion took longer for a
blind person and therefore failed to meet a time constraint. Every
single accessibility guideline could be followed to the letter and
still hit this problem.

Is this including the S508 accessiblity guideline that can be
paraphrased as "warn of time constraints and provide a mechanism to
extend time limits"?

On a practical basis the only way you are going to identify and rectify
issues of this sort is through the disciplines of usability analysis
and testing. This is an established field of computer science that has
a whole toolkit of methods to deal with exactly this sort of issue.
Accessibility tools on the other hand are demonstrably not going to do
the job - because every single part of the process is already
accessible.

True, but most of the WCAG Priority 2 and Priority 3 are not required
to access the content. They make it *easier* but aren't essential. So
the WAI itself chooses to define accessibility past the bare minimum
needed to access the content.

--
Chris

On your first point you would have to look at what was happening behind
the scenes. Having worked on on-line booking systems I would tend to
interpret the description not as a time limit per se, more as a simple
case of first-come-first-served. Where those who cannot complete the
task as quickly lose out.

Modifying a design to enable people to use it quickly and efficiently
is a part of what usability engineers do. I simply do not see how it is
helpful and useful to pretend that in the case of the web that it
suddenly becomes a new discipline called accessibility when there is
already an established discipline with all the tools and techniques in
place to deliver the real benefit.

--
Nic

On Fri, 14 Jan 2005, NicHughes blurts out without any citation or
context [please don't do that, it makes the discussion hard for
everyone to follow]:

In this example there was no step of the process that the person was
unable to complete,

Or as they say in a different context, "every surgical step was
carried out correctly - the operation was a complete success - but the
patient is dead".

the issue was that completion took longer for a
blind person and therefore failed to meet a time constraint.

Which meant that the /service/ which the page was intended to provide
was effectively inaccessible to them.

Every single accessibility guideline could be followed to the letter

That's not the point. Mere conformance with guidelines is not an end
in itself. If the overall process cannot be completed and a
successful outcome achieved, then the process *is* inaccessible, no
matter how accessible the individual steps might have been.

and still hit this problem.

Exactly the point that I was making: mere conformance to web
accessibility guidelines for the web page itself did not suffice
to make the /service/ accessible.

I simply do not see how it is helpful to regard this as an
accessibility issue

I simply don't understand how you can claim that it is not.

Certainly there are also usability issues - for example an average
user might be distracted during the course of the procedure - the
phone rings, or they have to go to the bathroom, or they need to check
some other resource, in mid-procedure - and then find they, too, are
"out of time" and the outcome of the overall process is failure.
But, at least in principle, such a person can avoid these problems
voluntarily. The reason that issues of this kind are discriminatory
in an accessibility sense, is that some users do not have the option
to proceed more quickly through the procedure.

- unless you have simply chosen to redefine the word for your own
personal use

Absolutely not, and I'm confident that I won't be alone in that
interpretation.

to mean something far more than it does to most people.

I can't agree.

Alan J. Flavell wrote:

On Fri, 14 Jan 2005, NicHughes blurts out without any citation or
context [please don't do that, it makes the discussion hard for
everyone to follow]:

The Google groups Beta is perhaps not stable enough for beta release -
and I'll pay more attention to its error messages in future.

the issue was that completion took longer for a
blind person and therefore failed to meet a time constraint.

Which meant that the /service/ which the page was intended to provide

was effectively inaccessible to them.

Given what I know about how these sites typically work "under the hood"
I do not think it is anything like so clear-cut. It is probably not a
fixed time constraint but could be better described as a race for the
given ticket by a number of users - the fastest gets the ticket and the
remainder are left only the higher-priced options.

Every single accessibility guideline could be followed to the
letter

and still hit this problem.

Exactly the point that I was making: mere conformance to web
accessibility guidelines for the web page itself did not suffice
to make the /service/ accessible.

Well quite, mere accessibility is not sufficient. It must also be
usable.

I simply do not see how it is helpful to regard this as an
accessibility issue

I simply don't understand how you can claim that it is not.

Because you will find no guidance on how to understand and resolve the
issues here in accessibility guidelines. If you want to resolve these
issues you need to understand usability.

The reason that issues of this kind are discriminatory
in an accessibility sense, is that some users do not have the option
to proceed more quickly through the procedure.

It is possibly a discrimination issue[1]. Caused by poor usability.

I can't agree.

Somehow I am not surprised in the least.

[1] Depending on the definition of discrimination you and your
legislators choose to adopt.
--
Nic

On Sat, 15 Jan 2005, NicHughes wrote:

Exactly the point that I was making: mere conformance to web
accessibility guidelines for the web page itself did not suffice
to make the /service/ accessible.

Well quite, mere accessibility is not sufficient.

*Now* I think I can see your problem. You're interpreting the term
"accessibility" as nothing wider than "web accessibility", or maybe
even as narrowly as "conformance to web accessibility guidelines".

Let me take a random example (picked out for me by google) from many:

http://www.ltd.org/site_files/access/

This web page is /about/ one aspect of accessibility. Let's not
discuss the accessibility of the web page itself, since that would
distract from the point I'm trying to convey. This site isn't using
the terminology of "usability of public transport", as it seems you
would want it to do, but about "accessibility of public transport".
And that's my point.

Now try e.g http://www.liv.ac.uk/library/info/libinf16.html

This tells us about "accessibility" services for a university library.
It doesn't talk about "usability services", as it appears that you'd
want it to do.

It must also be usable.

Of course. But discriminatory non-usability (in that some kinds of
user can make use of the service, even if its usability is less than
optimal, whereas others are unnecessarily denied use of the service by
the nature of some disability) is ipso facto an accessibility failure,
to my way of understanding.

I simply do not see how it is helpful to regard this as an
accessibility issue

I simply don't understand how you can claim that it is not.

Because you will find no guidance on how to understand and resolve
the issues here in accessibility guidelines.

Well, you've already been shown one example where they *are*: S508
calls, in effect, for the process to be so constructed that the user
is not impeded by an artificial time limit. And could I remind you
that Section 508 is not confined to the accessibility of /web pages/
alone?

<quote>
The standards define the types of technology covered and set forth
provisions that establish a minimum level of accessibility. The
application section (1194.2) outlines the scope and coverage of the
standards. The standards cover the full range of electronic and
information technologies in the Federal sector, including those used
for communication, duplication, computing, storage, presentation,
control, transport and production.
</quote>

If you want to resolve these issues you need to understand
usability.

Did I ever suggest that was optional? I may not be particularly good
at it, but that doesn't mean that I'm unaware of its importance.

Well, I've had my say. If your lexicon defines and scopes the
terminology differently, well, we'll just have to agree to differ on
terms, I guess.

Alan J. Flavell wrote:

On Sat, 15 Jan 2005, NicHughes wrote:

Exactly the point that I was making: mere conformance to web
accessibility guidelines for the web page itself did not suffice
to make the /service/ accessible.

Well quite, mere accessibility is not sufficient.

*Now* I think I can see your problem. You're interpreting the term
"accessibility" as nothing wider than "web accessibility", or maybe
even as narrowly as "conformance to web accessibility guidelines".

On the other hand you prefer to define accessibility as something that
cannot meaningfully be achieved by means of any of the accessbility
guidelines for non-trivial processes. I've find that definition rather
incompatible with the "well marked up structural HTML is inherently
accessible" line that tends to dominate this part of the usenet
heirarchy but as I never intend to use your definition its hardly
something I'm going to lose any sleep over.

Well, I've had my say. If your lexicon defines and scopes the
terminology differently, well, we'll just have to agree to differ on
terms, I guess.

Quite.

--
Nic