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.fihttp://hsivonen.iki.fi/