W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2001

RE: Inclusion or accessibility

From: Al Gilman <asgilman@iamdigex.net>
Date: Wed, 17 Oct 2001 10:37:04 -0400
Message-Id: <200110171427.KAA372236@smtp1.mail.iamworld.net>
To: "Mark Magennis" <mark@frontend.com>, <w3c-wai-ig@w3.org>

What is the business case for the guidelines you are preparing?

Without understanding how they are expected to contribute value added, it's
hard to know what to say they should _be_.  Including what slogan should be at
the masthead.  I think that you have amply demonstrated that _there is no
solution_ to be had by "putting the right slogan at the masthead."  You are in
a business, and your business is not special-interest advocacy, it is
consulting to industry.

Frankly, I'm pretty tired of guidelines. 

If I were searching for a precedent for something that would be effective in
delivering more accessibility and usability for all (in the products and
services actually reaching the market), I would think in terms of the
Capability Maturity Model of the Software Engineering Institute.  Not that
their specific scale is what we need for product designers; but the mode of
engagement is a candidate for  replication.  

The evaluation should be split 50:50 with regard to the output of a design
pipeline and the workflow rules in the pipe.  It should be performed by an
outside team.  It should be repeated (semiannually?  every 18 months?
Maybe there is an additional rule that the outside team should be different
from snapshot to snapshot?

This is something like the shape of a mode of engagement between a consulting
organization and an organization that designs products or services that could
make an actual difference.

The one I am wrestling with currently is selling "the documentation of
pluggable interfaces."  Why it is important, what it entails.  

Logically this is a correlary of the both-and of maximizing the robusness of a
given [product or service] and [compatibility with product extension through
assistive technology or rollover through referral to an alternate channel of
service].  But everyone you have to get to follow this finds it hard to back
off to the point where it is clear that they fit the pattern of where this
should apply.

What I want the Grid architecture to adopt is "every function knows how to
be a
server."  It knows how to deliver OEM levels of accepting steering from a
downstream partner, and providing model knowledge for the interpretation of
data shipped.  But dissemination -- getting the people who have to do it to
recognize the need -- that's not rolling off the tip of my tongue.

Have you been through
This is where we try to do what you are attempting for the Global Grid Forum. 
People bent on turning the Internet and Web into a world-wide plug-and-play
service composition capability.  So plug and play is the name of the game;
that's not a question.  But they _still_ don't want to accept that they
have to
design in ignorance of who their downstream neighbors are going to be.  Open
systems are scary.

So I am reduced to trotting out examples in the current in_use technology. 
Screen readers are not the only things that intervene between "the user
interface" and the user.  Atomica lives in that N+1st tier, too.

My suggested answer to your predicament:  The top level protocol is a method
for optimizing the value received by product/service consumers in the presence
of diversity in the service delivery context particulars.  Check the DI
principles draft, but watch for improvements yet to come.  Your customers want
to make their product or service better than what their competitors develop,
for their customers.  How to make it better is something you can sell. 
Experience teaches that if you don't apply structured methods to de-sensitize
the optimization to customer situation diversity, you lose, because you
accidentally create results you didn't anticipate for lots of consumers in
situations you didn't experience during the design process.  [you fill in the

Good luck!


At 08:15 AM 2001-10-17 , Mark Magennis wrote:
>Jonathan Chetwynd wrote:
>> I'm after about 3 years at wai getting a feeling that
>> accessibility doesn't
>> describe what is needed and maybe inclusion does.
>> Any ideas on this thread welcome
>I've been wondering about this a lot lately and I would love to get feedback
>on my wonderings from members of this forum.
>As background, my company, Frontend, are involved in writing accessibility
>guidelines for services delivered through IT channels. This covers not just
>the Web, but everything from bank cash machines to mobile phones and desktop
>software. All information technologies.
>A question that has come up for us is: are we trying to promote Universal
>Design, Inclusive Design, Design for All or Accessibility?
>We are wondering which term to use because we're beginning to think that it
>matters quite a lot. Although our original brief was to produce
>accessibility guidelines to help secure the rights of people with
>disabilities, we have heard a number of comments, such as the following:
>- “Disabled people are only a small number of our users so it doesn’t make
>sense for us to cater specially for them”
>- “You’re focussing too much on the medical model of disabilities which
>pigeon holes and segregates people”
>- “How can we possibly design for everyone? It’s just not feasible. And
>anyway old or blind people aren’t going to be working on a flight deck”
>We’ve come round to thinking that the term Inclusive Design best sums up
>what we are trying to achieve, whilst getting around some of the objections
>we’ve heard. It also allows us to focus on the benefits to the developers
>and service providers themselves, which is particularly important in the
>public sector. Ultimately, we think it will be the best way of promoting
>accessibility. I’d like to describe what we mean by Inclusive Design and why
>we like the term.
>Before going further, I should stress that we are not saying that the term
>Inclusive Design is always better than either Universal Design or
>Accessibility, or vice versa. Just that we think it better fits our aims. We
>see accessibility as a part of Inclusive Design in the same way that he Web
>is part of IT. We do not wish to criticise this forum or any individual for
>focussing on these specific aspects. This is absolutely necessary, even
>within Inclusive Design.
>The reason we like the term “Inclusive Design” is that it puts the emphasis
>on the benefits to the developer or provider of including as many of the
>potential users as much of the time as possible. It recognises that people’s
>abilities vary in many ways and the abilities of a given individual will
>vary across situations. It encourages designers and service providers to
>include all these different individuals and different situations. To avoid
>excluding potential users, either temporarily or permanently, by failing to
>take into account the physical, mental or environmental constraints they may
>be operating under. It is therefore realistic and wide ranging in its
>Although it includes the notion of “Accessibility”, Inclusive Design does
>not restrict itself to people who are “disabled”, which is often thought to
>be a small community and therefore not particularly important from the
>providers point of view. It therefore avoids segregating and pigeon holing
>people with medically-recognised impairments. By focussing on abilities
>first and the people who have them second, it illustrates that we can all be
>impaired in certain ways at certain times and it is nothing unusual.
>Unlike “Universal Design” or “Design for All”, it does not urge designers to
>ensure that “everyone” can use a product or service. This aspiration may
>well be unnecessary or unachievable in practice. If so, it will be dismissed
>on the basis of being unrealistic.
>The concept of Inclusive Design is easier to connect to the broader concepts
>of “customer-focus” and “usability”, both of which are already taken
>seriously by designers and providers of IT products and services. It is also
>perhaps a more mindset-oriented term. For example, designers could have an
>inclusive attitude. Accessibility is perhaps a bit more technical-oriented,
>like it’s either accessible or it’s not. However, promoting Inclusive
>Design, which is easier to sell on benefits, should ultimately be a good way
>of promoting accessibility, which is one of the requirements for it.
>That’s where we are at right now. All comments appreciated.
> _______________________________________________________
> Dr. Mark Magennis                     Head of Usability
>   Frontend - Usability Engineering & Interface Design
>   40 Westland Row, Dublin 2, Republic of Ireland
>          Visit our Usability Infocentre at:
> mark.magennis@frontend.com         tel: +353 1 241 1616
> <http://www.frontend.com/>http://www.frontend.com            fax: +353 1 241
> _______________________________________________________
Received on Wednesday, 17 October 2001 10:27:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:14 UTC