Reality Check: Bi-polar Accessibility Disorder (BAD)

I think Rob has made some rather profound observations in this post.

>> First, I think most of us here, even those who do not see themselves
>> primarily as "accessibility advocates", would agree that it's
>> important to support accessibility. No one has disputed that part of
>> the design principles.

Can we as a working group agree to stand by this as a principle that we
_all_ support accessibility. The many sundry discussions that then arise
about how we do this should all naturally stem from this principle in
the first place - then we can get somewhere as the following arguments,
debates and discussions will then all be working towards the common
organisational goal of making HTML 5 an excellent, inclusive specification.

>>Here's the major divide I see,
>> and these are somewhat extreme statements of the two positions:
>>
>> [Position A]: Accessibility is important. Therefore we should have a
>> lot of HTML features that are there specifically to aid accessibility
>> for some classes of users. 

We should have all the required or necessary
features/elements/attributes that serve the specific needs of people
with disabilities in a way that is as easy as possible to author with as
little room for ambiguity as possible. Like this attribute serves a
person who is visually impaired and the user agent should render it in
such a manner etc. In other words maybe there is a dearth in the WG
(though in truth I doubt it) of knowledge about what people with
different disabilities really need and how  their needs can be met.

If anyone has first hand experience of having a disability, or working
with people with disabilities then they will have some rather clear,
focused and down to earth ideas about what works and what doesn't when
it comes to browsing the Internet or using computers. I happen to be
lucky enough to have several years of this hands on experience so I
guess that has opened my eyes to a couple of things.


>>Authors should be required to add as much
>> accessibility stuff as possible to their markup.

When required, yes, and what is wrong with that?  I don't think authors
want to discriminate against anyone, and many want to do their best,
they are often unaware that their bad authoring practices are creating
accessibility issues or barriers and when they have their eyes opened
they usually never go back.

> Quoting Maciej Stachowiak <mjs@apple.com>:
>> [Position B]: Many authors won't think that much about accessibility.
>> So the best accessibility enhancements are those that work on top of
>> features that also have some benefit in mainstream browsers with no
>> added AT. In the course of making the right markup for general use,
>> accessibility comes along for the ride, and that's basically all we need.

> Perhaps this is an equally extreme straw man statement of position B,
> however it does seem more in line with what I've been reading on this
> list. That is, we find many suggesting that accessibility should mostly
> be just a celebration of happy coincidences where certain aspects of
> HTML and Unicode text and the human senses just happen to be able to
> provide a way for disadvantaged users to consume — from time to time  —
> minor tidbits of content that non-disadvantaged users easily consume
> completely. 

>Perhaps it is because it is stated in an extreme way, but
> this looks to me exactly like a statement that HTML should not have any
> accessibility facilities.

It does look a little like that alright and I don't think thats good
enough. You cannot expect through some random 'put it all in a blender'
approach and make semantic curry paste, that it will satisfy the senses
of everyone! It won't. There needs to be explicit associations,
bindings, whatever, so authors know what they are doing and why they are
doing it. Piggybacking accessibility features on the back of other
features to me sounds daft. Tooltips anyone? IMO that is an example of
where that approach could lead where a really useful attribute is often
used for a completely different purpose. Where many authors go, 'Who
cares if its an accessibility feature - it does this cool pop up thing
when I mouse over it!'. What other horrible hacks, or non-intended
renderings await without explicit reasoning, association, binding,
technique etc?

> Often times (like in the case of @headers) the attempt to purge
> accessibility features from HTML [...]

We should certainly be careful not to throw the baby (babies?) out with
the bathwater.

> Quoting Maciej Stachowiak <mjs@apple.com>:
>> Notice that there is no debate here about whether accessibility is
>> important. The disagreement is solely over the best way to address it.

I really want to take that statement at face value.

>Your statement of position B was basically that HTML
> should not include facilities if they would only be useful for a
> disadvantaged web user. Laclan has made similar arguments: insisting
> that documents should only include elaborations of non-text media if
> those elaborations would be useful to non-disadvantaged users (in other
> words those who can already consume the non-text media).

If this is the case Rob, then it is worrying. Why? Because often there
will be a _need_ for features/elements/attributes that *do* specifically
serve people with various disabilities and maybe their is no back door
for them or way to piggyback them in on other more important features
for *normal* users, the masses, or whatever. This WG is just going to
have to face the fact that those with specific alternate requirements
may need more attention that the *rest* of us (again I have never met
any normal users) and therefore we *do* need specific and explicit
features/elements/attributes to serve them.

> Quoting Maciej Stachowiak <mjs@apple.com>:
>> When advocates of Position B argue for accessibility solutions that
>> work automatically with standard markup, and against explicit
>> accessibility-specific markup, sometimes advocates of Position A see
>> this as being against accessibility. At this point, they may criticize
>> advocates of Position B as being against human rights. They sometimes
>> argue that instead of making normal markup work well, we should force
>> authors to add more accessibility-specific markup; it is sometimes
>> claimed that various laws may require this.

If position B worked, then fine. But does it work? Also using language
like forcing authors is a little strong IMO. Teaching authors the right
way of doing the right thing is one up hill struggle that is definitely
worth making.

> Quoting Maciej Stachowiak <mjs@apple.com>:
>> I hope you can see how this may be frustrating. I think advocates of
>> Position B are mostly sincere in their belief that their approach is
>> the better way to improve accessibility. [...]
> This is not merely a technical disagreement. Both positions agree that
> UAs should follow accessibility guidelines.[...]In other words is there any
> semantic features that HTML can include that will improve the experience
> of disadvantaged users when compared to other non-HTML approaches. I've
> said this before, but it bears repeating. HTML's focus on semantics is
> what makes it a a leader in providing accessible content. 

Very well said Rob.

>The goals of
> semantic markup and accessibility go hand-in-hand: because semantic
> markup presumes nothing about its presentation (whether aurally,
> tactilely or visually). Adding a few other features like TABLE@summary,
> TD@abbr, and non-text media fallback, is just a minor extension of the
> semantic capabilities already inherent in HTML.

Exactly, and also just for the record, before some of them potentially
go in the bin, let us meditate on the millions of people who have
benefited from the addition of some these _minor_ features within HTML.
It's true.

> Quoting Maciej Stachowiak <mjs@apple.com>:
>> On the other hand, sometimes it seems that advocates of Position B ask
>> advocates of Position A to jump through a lot of hoops to justify
>> accessibility features that are already in HTML4. And it may seem that
>> these kinds of hoops are not always required for features that aren't
>> related to accessibility.
>>
>> I think in some ways this is a fair criticism. But I think the best
>> way forward is to carefully examine and justify all HTML features, to
>> make sure we have a solid basis for our working group decisions, and a
>> record of the reasoning. 

Then that is a sound argument for having explicit accessibility related
bindings, associations and authoring techniques so we *are* clear about
what does what and why.

> Though I am trying very hard, it is difficult for me to even begin to
> understand the position that would advocate the removal of these few
> small features of HTML that benefit both authors and users. Many of
> these features already have (at least limited) implementation support.
> Even the requirements that authors must provide equivalent fallback for
> non-text media is so easily circumvented (unless laws and other mores
> intervene) that it's hared to imagine what possible costs could be
> involved in including these features. If there really is a concern that
> including accessibility features in HTML will only make authoring more
> difficult because of legal ramifications, then that's a conversation we
> should have openly here on this forum. It shouldn't be dealt with by
> fostering and proliferating an attitude of contempt for accessibility
> throughout the web community.

Again Rob, very well said.

Josh

Received on Tuesday, 31 July 2007 22:01:27 UTC