W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > January to March 2003

Re: "What is Web Accessibility?" slide

From: Charles McCathieNevile <charles@sidar.org>
Date: Mon, 10 Feb 2003 16:23:19 +1100
Cc: w3c-wai-eo@w3.org, pjenkins@us.ibm.com
To: Al Gilman <asgilman@iamdigex.net>
Message-Id: <C43A4F78-3CB7-11D7-B881-000A95678F24@sidar.org>

It is a little difficult to respond without seeing all the context. I 
looked through the group archives, but it was not entirely illuminating.

I agree with Al that we should remember that what we mean by an 
"accessible Web" is narrower than what people in the wide world 
understand. But I don't have any heartburn about using the term like 
this.

I also agree that the suggested phrasing confuses the "what is" with 
the "how do we make". I think Al's suggested approach of saying:

> an accessible Web is a Web where:
>
> - the user can grasp the information that web content is trying to 
> tell them,   limited only by their ability to understand, not by any 
> artifacts of the medium of expression.
>
> - the user can attain any outcome that Web applications are trying to 
> offer them.
>
> - the user can remain confident that they are directing the course of 
> the dialog

is a much better approach, although it could do with some editing. (I 
also like short slides. In an online presentation there is room for 
more than in slides which are used in a talk, but the draft below seems 
very long).

It should then be followed by a slide or two that talks about how this 
can be achieved, and the fact that there are different parts to the 
puzzle. (I would use two - one on authoring, which includes standards 
for content and tools that support that, and one on tools people use to 
get to the content, that support the standards and requirements. Your 
mileage may differ...)

On Phill's point about

> - software used to access the Web
>          * that can be used by people with disabilities,
>          * and that works with technologies that some people with
> disabilities use

My assumption  is that this is a three-line explanation of UAAG and its 
role, and it seems to compress too much.

Outside the office-bound desktop-plus-assistive technology there are 
real hardware issues in using browsers. Mobile phones, PDA's whether 
visual, voice or braille based, kiosk-style terminals, cash registers, 
internet refrigerators (being heavily promoted in melbourne right now) 
and the like are often not very flexible about how you can interact 
with them, yet they are taking on more of the role of providing access 
to the Web for work and civic participation. This is in addition to the 
software that they use to access the Web - in some cases it also 
encompasses their own operating system software. So the issues strike 
me as including both the hardware and software people use to access the 
web, and that this needs to be usable by everyone, configurable to suit 
their preferences, and able to work with any additional hardware or 
software they require to support their needs and preferences.

Sorry for the delayed response. I spent some time trying to find more 
context for the slide, but couldn't.

cheers

Chaals

On Friday, Feb 7, 2003, at 04:13 Australia/Melbourne, Al Gilman wrote:

>
> Judy asked for comments on the slide content as follows:
>
> <quote
> cite="">
> Our latest version, as of today's discussion, and on which I'll be 
> asking
> for feedback on from the WAI CG (Coordinating Group):
>
> What is Web Accessibility?
> -------------------------------
> An accessible Web is one that can be used by people with disabilities, 
> and
> also benefits other users of the Web. Web accessibility includes:
>
> - content that is presented in a way
>          * that can be perceived, operated, navigated, and understood 
> by
> people with disabilities;
> - software used to access the Web
>          * that can be used by people with disabilities,
>          * and that works with technologies that some people with
> disabilities use
> - software used to build Web sites
>          * that can be used by people with disabilities,
>          * and that supports creation of accessible Web sites;
> - technologies that underly the Web (HTML, CSS, SMIL, XML, etc)
>          * that support accessible Web content and software.
>
> </quote>
>
> Yes, I have serious heartburn about this slide.
>
> What the WAI provides is knowledge about what it takes for the Web to 
> be
> accessible, where "accessible" in this context means "accessible to 
> people
> with disabilities."
>
> Stating that that is what "an accessible Web" *is* (implying outside 
> of the
> discourse conducted on the W3C site) is an affront to the autonomy of 
> every
> reader of this material.  Don't go there.  It is placing a gratuitous
> barrier in the way of having the reader sign on to follow our lead.  
> Making
> the message inaccessible.
>
> There is also a problem that Wendy raised: the breakout that follows
> reflects a backward-looking view of what the Web is.  This still 
> reflects
> the Web one can browse today, but it does not describe the Web that the
> people PF talks with are building technologies for.
>
> But the real problem is not this obsolescence in the "what is the Web" 
> story
> assumed.  More fundamental than this accidental obsolescence is the
> unfortunate mixing of 'how' into 'what.'  Break these out and tell both
> stories.  "*What* an accessible Web *is* (in the context of the WAI
> publications) is a different matter from *how* to have an accessible 
> Web
> (which is the topic of the WAI publications).
>
> The public controls the "Journalist's Agenda" of topics: who what when 
> where
> why and how.  If we haven't decomposed our story enough to distinguish 
> among
> these primitives, we are not speaking in the common rhetorical 
> vernacular.
> It's not just simple words, it simple story lines and roles within the 
> plot
> that will make our story accessible.
>
> If we in the WAI are not re-factoring [see Extreme Programming] our 
> understanding
> of our customer, the Web; and re-grouping our efforts around a 
> forward-looking
> map of where the action is in creating the to-be Web, we will always 
> be at least
> one technology generation behind in our assistive provisions, and we 
> won't even
> be able to keep up with maintaining that, to boot.
>
> What we need on this point is something more or less like the 
> following statement:
>
> "When we in the WAI talk about an 'accessible' Web, we mean "a web 
> that is
> accessible to people with disabilities."
>
> What's the difference?  We don't claim that this is what an 
> 'accessible' Web *IS*,
> i.e. what this language should mean in any and all discourse contexts, 
> but rather
> we take a humbler posture and _describe_ for the reader a short-cut 
> form that we
> will habitually use because we need to refer frequently to this 
> concept whose
> plain-language statement is a nested prepositional phrase.  But that 
> nested
> prepositional phrase employs a syntactic form that is controlled by 
> the vast
> majority of speakers of English World-wide, and in the expanded 
> adjective phrase
> form, it does not depend on any Terms of Art -- it uses terms that are 
> current
> in the common parlance in their common senses.
>
> I am not sure if you want to include the development below in your 
> overview stuff.
> It is how one should teach this patch of usage conventions, however:
>
> accessible [Webster] ::= readily grasped (to a user)
>
> [aside, to be developed in a footnote, but must be understood to see 
> why
> the next is said as it is.]
> the Web is both a medium in which information is delivered and actions 
> accepted from users, and a corpus of services engaged in those 
> activities.  Users don't distinguish between the medium and the 
> message.  [Here message == service, wherein web documents afford an 
> information-transmittal service.]
>
> an accessible Web is a Web where:
>
> - the user can grasp the information that web content is trying to 
> tell them,   limited only by their ability to understand, not by any 
> artifacts of the medium of expression.
>
> - the user can attain any outcome that Web applications are trying to 
> offer them.
>
> - the user can remain confident that they are directing the course of 
> the dialog
>
> a Web which is accessible to people with disabilities is one where the 
> above three qualities are sustained in the presence of human 
> conditions impairing functions often employed in the human-computer 
> interaction of the user engaged with the above services.
>
> a Web which offers equal access to people with disabilities is one 
> where the performance on the above three axes: complete delivery of 
> information, complete
> access to outcomes, and effective command of the process -- is 
> subtantially the
> same for people with disabilities and for people without disabilities.
>
> Recap:
>
> To make what we mean by various terms clear, we
>
> - must not make it sound as though we assume people should always 
> equate
> accessibility with PWD accessibility.  I.e. recognize and affirm the 
> general
> sense of 'accessible.'  Distinguish _our_ use of 'accessible' from what
> 'accessible' 'is' already to our audience.  There is a great line on 
> this in
> the current CACM in the article by Philip Agre "P2P and the Promise of
> Internet Equality[1]." He points out that technologists turned social
> advocates are singularly naive in failing to start with an assessment 
> of how
> the public _already_ views the issue where they wish to sway public 
> opinion.
> We have fallen into the same trap on this one.  We don't define the 
> topic.
> We have to engage with the topics that the public perceives.
>
> - distinguish between 'accessible' and 'equally accessible' because 
> the bulk of experience falls within the difference between these two.
>
> Those are the basic must-haves in this phase of our exegesis.
>
> In addition, this slide degrades our exposition of what it is for the 
> Web to
> be accessible (to PWD) -- which is simply a matter of the user's 
> experience.
> This slide mixes in a deployment of "what it takes for the Web to be 
> accessible"
> based on a backward-looking model of what _the Web_ is.  This is bad 
> on two
> counts.  Don't mix the statement of what it is to be accessible -- 
> which is in
> in operational performance terms in the user's experience -- with 
> methods for
> attaining this outcome.  Those have to be on two different slides.
>
> The bottom four bullets address "how the structure of the WAI 
> Technical Activity addresses the issue of ensuring that the Web will 
> be accessible."
>
> That is a very different issue from what "an accessible Web" 'is.'  
> And we should not make that the question, anyway.  Make it "The 
> accessible web we are talking
> about _here_ is <explanation/>."
>
> Al
>
> I am copying Phill and Chaals because they did yeoman duty in the 
> QuickTips caper.
>
> [1]  Communications of the ACM February 2003/Vol 46, No 2, p. 39.
>
>
--
Charles McCathieNevile           charles@sidar.org
Fundación SIDAR                       http://www.sidar.org
Received on Monday, 10 February 2003 00:23:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:55:50 UTC