RE: Inclusion or accessibility

Al Gilman asks how our IT guidelines are expected to contribute added value
and says he is "pretty tired of guidelines", citing the Capability Maturity
Model of the Software Engineering Institute as a more effective tool for
promoting accessible design.

That's very interesting, because we may be developing from our original idea
which was to produce "accessibility guidelines for IT", something like the
WAI guidelines but for the whole of IT. Obviously, that's a pretty tall
order and the plan was always to reference existing guidelines where they
exist and are authoritative (like WAI) rather than recreate them. With that
in mind, we shifted to the idea that what we were producing was an overall
user interface to information that mostly exists already but is not
necessarily usable for all the people who would want to use it. For example,
the WAI guidelines have so far tended to be aimed at the technical
development level, notwithstanding the recent drafts concerning business
arguments. These and other guidelines tend also to be aimed at
"accessibility", despite the inclusion of introductory paragraphs outlining
how they also apply to sighted people surfing and driving at the same time.

So we want to provide a structure and interface to this type of information
that is geared to all the different types of users - engineers, business
managers, government procurement managers, etc., and we don't want to just
give them guidelines along the line of "this is a problem, this is the
solution", this is another problem, this is the solution". Of course we do
want to do this, but not only this, and that's where Al's reference to the
Capability Maturity Model comes in.

This model basically tells you where your organisation is on a maturity
scale of 1 to 5 in the way it produces software. More importantly, it tells
you, at each level, what you need to do to get to the next level. That's
extremely useful. It really helps you take your organisation forward to
become better and better at what you are trying to do. But it is not
guidelines. Unlike Al, I am not tired of guidelines. I think they are
necessary and useful. But, like Al, I'm intrigued by the possibility of
offering more than just guidelines. Things that will help developers create
a process of inclusive design and, starting where they are now, to mature
that process. Things that will help organisations create a culture of
inclusivity. Our vision for our "guidelines" therefore includes process
outlines, business arguments and awareness-raising materials as well as "do
this" guidelines. That's as far as we've got at the moment and it seems to
have taken me a long time to say it, but the question is, what else, on top
of guidelines, do we need to offer people who are developing or procuring IT
(or in this case Web) products and services that will be inclusive.

Mark


> -----Original Message-----
> From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
> Behalf Of Al Gilman
> Sent: 17 October 2001 15:37
> To: Mark Magennis; w3c-wai-ig@w3.org
> Subject: RE: Inclusion or accessibility
>
>
> Mark,
>
> 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 .
>
> 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?
> dunno).
> 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
> feasible
> 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
> <<http://trace.wisc.edu/docs/ud4grid/>http://trace.wisc.edu/docs/u
> d4grid/>?
> 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
> details.]
>
> Good luck!
>
> Al
>
>
>
> 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
> >benefits.
> >
> >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.
> >
> >Mark
> > _______________________________________________________
> >
> > Dr. Mark Magennis                     Head of Usability
> >
> >   Frontend - Usability Engineering & Interface Design
> >   40 Westland Row, Dublin 2, Republic of Ireland
> >
> >          Visit our Usability Infocentre at:
> >       
> <http://www.frontend.com/usability_infocentre/>www.frontend.com/us
ability_in
focentre/
>
> mark.magennis@frontend.com         tel: +353 1 241 1616
> <http://www.frontend.com/>http://www.frontend.com            fax: +353 1
241
1601
> _______________________________________________________
>

Received on Wednesday, 17 October 2001 13:27:49 UTC