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

On Jun 26, 2007, at 22:57, John Foliot - Stanford Online  
Accessibility Program wrote:

> the folly of <b> and <i> (and what exactly does italicizing the  
> text mean?)

As an aside, I think <b> and <i> aren't folly but pretending that  
changing their names to <em> and <strong> solves something is.

> and a protracted even hostile discussion surrounding the need to  
> preserve headers and ids for
> tables (as but 3 examples that spring to mind).

Yeah, but on the other hand, it isn't helpful to say that "foo is  
vital for accessibility" without saying why and what to write as the  
processing model in the spec in a way that makes sense for the long  
term (in the case of headers='' so that the processing model also  
takes into account scope='' as well as implicit "obvious" default  
association).

> We've not heard one word of
> the accessibility friendly features being proposed.
>
> Perhaps some concrete examples would be apropos?

<section>, <header> and the outline algorithm
These features provide a standard way to generate an outline for an  
HTML document. The outline can be used for jumping directly to an  
interesting part of a long document.

<article>
This element enables a "Skip to content" feature in UAs where the  
user can't get a quick overview by glance (e.g. aural UAs and visual  
UAs constrained by a relatively small screen).

<aside>
This element lets non-visual UAs indicate to the user that a given  
piece of text is not part of the main flow of thought. (Failure to  
indicate this could potentially be confusing.)

<footer>
Provides for skipping over administrative information in e.g. aural  
UAs when the user wants to scan a page as quickly as possible  
omitting such notices.

<nav>
Enables "Skip over navigation" and "Skip to navigation" features in  
UAs where the user can't easily navigate spatially (non-visual or no  
pointing device).

<figure>
The association of a caption with the element being captioned and the  
suppression of the caption when a text fallback is used is at least  
well-intentioned to support the needs of blind readers. Whether the  
design actually meets these needs is debatable judging from recent  
comments.

<m>
Makes it possible for non-visual UAs to indicate that a particular  
run of text was highlighted by e.g. a search engine so that a user  
might want to skip to it. (Again, well-intentioned. Whether it is  
actually workable is debatable.)

<meter>
Provides for AT access to the state of a gauge widget while making it  
super-easy to make visual gauges that do the right thing AT-wise.

<time>
Hopefully helps the microformat community stop polluting the title=''  
attribute of the <abbr> element in ways that interfere with the aural  
Web browsing user experience.

<datagrid>
Provides for AT access to complex grid widgets e.g. in browser-based  
email apps like Gmail.

<details>
Provides for AT mapping to the UI idiom that in (for example) the Mac  
native UI is visually represented by the disclosure triangle.

<datalist>
Makes it easier for users to fill text fields. Provides for AT  
mapping to the combobox UI idiom.

<output>
Makes it possible for AT to flag a piece of content as the changing  
result of a calculation. (I have no idea how useful this is in  
practice of how aural UAs or screen readers deal with script-based  
document mutations in general.)

<progress>
Provides for AT access to the state of a progress bar widget while  
making it super-easy to make visual progress bars that do the right  
thing AT-wise.

Various additions to <input type=''>
Make it easier to adapt input methods to the kind of data the form  
field asks for. For example, if the field wants a number, a speech  
recognition input method could restrict itself to trying to recognize  
numbers only.

The repetition model buttons
Make it possible for AT to indicate that a given button adds or  
removes a repeating part (as opposed to indicating a generic button).

irrelevant=''
Makes it easy to flag parts of the DOM irrelevant for the current  
moment in time in the life cycle of a Web app UI view so that AT  
should not try to present those parts to the user.

>> However, for the custom widget case, ultimately native elements for
>> all available roles and XBL for custom widgets would be a more
>> elegant long-term solution. I do realize, though, that the main
>> advantage of role='' over XBL is that role='' doesn't require the
>> deployed installed base of browsers to participate as a whole in
>> order for expert authors to target the browsers that do participate.
>
> And this argument (and variants of it) have been coming from the
> accessibility folk for some time.  Henri, go back and research the  
> archives,
> and see how often it's been countered with "... The majority will  
> never do
> it..." type responses.  It is one of the key threads in the Pave the
> Cowpaths discussion.  Not everyone can be an expert in everything,  
> but for
> those who do specialize in ensuring accessible content ("expert  
> authors"),
> the tools must exist.  Too often, what we've heard instead is that  
> there
> needs to be a large enough use-case, or that there are currently  
> not enough
> viable examples in the wild, or what-ever.  All of these arguments  
> have
> essentially negated the role (and importance) of said 'expert  
> authors', and
> their needs.  Our needs may be edge-case, but they are real none- 
> the-less.

If you come and say that you want a given edge-case solution in the  
spec just because you know you think you need it, you are likely to  
be unsuccessful. On the other hand, if you present a use case,  
present a clean common case solution and *then* as an extra present  
coverage for edge cases *and* explain why the edge case coverage is  
not just chasing for diminishing returns, you are much more likely to  
be successful even if the edge case stuff is the same in both cases.

> Of course, but then again, the WG also
> are hoping that these tools will support other new ideas like  
> <canvas> and
> <progressbar>.  But as you note later (below), attributes such as  
> @role
> already have some UA/AT support today, so there is a business case  
> to add
> this capacity to authoring tools today as well.

Chances are that when authoring tool vendors assess business cases,  
<progress> will have enough of a business case to go with it even  
without considering accessibility whereas the business case for  
role='' hinges on accessibility considerations only.

>> 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.
>
> Am I hearing a fundamental shift in attitude?  If yes, then hurray!

In my personal attitude? Not really.

> (I am still very wary of @class, and it's misuse in "the wild" today),

The class idea got dropped weeks ago.

> In short, we should not need to argue for any accessibility  
> construct that
> already exists - if there is a better way forward, then fine, but the
> "removal" of any the existing tools should not ever be debated:

Existing as in "existing in a spec" is not good enough. For something  
to be considered existing, it needs to be implemented in a way that  
works. The debates are part of the finding of fact on whether  
something exists in this latter sense. It is frustrating for those  
who already know, but it is something we need to go through in order  
to define processing models that are compatible with the existing  
implementations.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 27 June 2007 09:55:24 UTC