RE: the market hasn't spoken - it hasn't bothered to listened [was Re: fear of "invisible metadata"]

Henri Sivonen wrote: 
> "I agree that HTML5 will need to have role='' and headers='' as short-

> term measures and as overrides for handling corner cases when easier- 
> to-author methods fail. It is rather pointless to make non-conforming

> something that Firefox and JAWS already support.
> However, I think they should be presented as short-term measures and  
> as overrides when other ways fail instead of being presented as  
> primary way of making HTML accessible on the long term. And the HTML  
> WG should seriously consider the long term."

Hi Henri,

If that is the direction of the WG, that sounds great.

One thing I'd point out though, is that accessibility use-cases
shouldn't necessarily be dropped due to (some of them) being edge cases.

Taking the organisational point of view, certain large organisations
(e.g. government departments) have to produce accessible content across
the board.
Sometimes these organisations have to produce certain content, such as
complex tables that have to look a certain way that (I don't think)
could be covered by the simpler mechanisms proposed.

I don't want to bring in the tables headers issue in here, but just use
it as an example illustrating that sometimes there are edge cases that
should be covered that may require extra effort by authors. For those
relatively rare cases where they need to produce a complex table,
application or whatever, they can put in the extra effort and make it
accessible. (E.g. we occasionally get asked to make annual reports and
similar documents into accessible PDFs.)

So long as the basic mechanisms work for the majority, that's fine, just
don't rule out the (accessibility) edge cases based on numbers, or
necessarily how difficult they are (although easier is always better).
If HTML5 can't support those edge cases, it will push organisations to
other formats.

Kind regards,


Alastair Campbell         |  Director of User Experience

Nomensa Email Disclaimer:

Received on Thursday, 28 June 2007 08:16:24 UTC