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

Henri Sivonen wrote:
> 
> I guess the new HTML5 features need a lot more marketing as
> accessibility features. It is kind of sad that the accessibility
> interest part of the blogosphere has focused on the HTML 5 draft not
> having certain attributes (yet) and not noticing how many new
> features have accessibility-friendly semantics without needing
> annotations specifically for accessibility.

Henri, here you make a superb point.  What the accessibility community has
seen (and heard) so far has been essentially confrontational responses from
the working group.  I am thinking of debates such as using @class to extend
semantic meaning (and the whole <span class="copyright">Nothing to do with
copyright, but needs to be fine print</span>) debate, the folly of <b> and
<i> (and what exactly does italicizing the text mean?) and a protracted even
hostile discussion surrounding the need to preserve headers and ids for
tables (as but 3 examples that spring to mind).  We've not heard one word of
the accessibility friendly features being proposed.  

Perhaps some concrete examples would be apropos?

> 
> 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.
In another response, you wrote:

> I still find it curious how accessibility experts have faith in  
> authoring software gaining all manner of features while at the same  
> time assuming explicitly or implicitly that AT will be more or less  
> frozen to its current state.

Authoring software can be as 'complex' as notepad, and if that is the only
tool I can have to improve accessibility as an 'expert author', then that is
the tool I will use.  Will it be time-consuming? Yes.  Is this efficient?
No.  Does it improve the content for our edge-case constituents? Yes, and
that is why I will do it.  Do I wish that next-gen authoring tools
would/could support these capacities? 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.

The other thing to keep in mind is that the rate of adoption of some
Adaptive Technology is much slower within the user community that requires
it, due to the (sadly) general fact that this constituency is often living
much closer to the poverty level, coupled with the fact that Adaptive
Technology can be quite expensive.  Tools such as JAWS can cost in excess of
$1,000 USD (https://sales.freedomscientific.com/category.aspx?categoryID=11)
- so while it may not be "frozen", next-gen adoption of Adaptive Technology
can be severely arrested - even though JAWS is at version 8, I know many
users who are still using JAWS 6 today.  And while there are some emerging
open-source AT tools today, the reality is that few software developers are
interested in this arena, as the user-base is small(er).  This is but
another reason to continue to support what we already have today, not remove
it.

> 
> 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!

> 
> 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.

Which perhaps it has been, however I think that they lost sight of the short
term, which has been (I suspect) the cause of some consternation in the
accessibility community.

> 
> That is, I still think that <progress> is the curb-cut installed as
> part of the routine paving process in the front of the building and
> role='wairole:progressbar' is the retrofitted ramp leading to a side
> door. A retrofitted ramp is better than no ramp, but surely we should
> make something better for new construction.

....and if this is the "new" way forward, then I for one am ecstatic.  

Henri, the accessibility community have fought hard for "enhancements" such
as @role, even if they require expert-author status to implement (our
community does a lot of train the developer outreach too); however this is
better than nothing at all.  What we were seeing (perceiving?) was a lot of
this progress was going by the wayside.  We need things like headers and id,
and longdesc (!!), and "proper" ability to add semantic meaning (I am still
very wary of @class, and it's misuse in "the wild" today), and @role for
AJAXian on-screen widgets.  If the working group can come up with more
elegant solutions, that are easier to implement and truly delivers what we
need (scope does not equal headers/id!), then we will cheer.  But in the
interim, we cannot afford to lose what we already have - a fear that earlier
threads have planted within our community (and I am not the only one who has
felt this way).

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: leave what
we have until a better solution exists and is supported, even if it is
difficult, or complex to do, or edge-case.  I sense that this is also what
your post is suggesting, and if that is the case, then we are on the same
page.

JF

Received on Wednesday, 27 June 2007 18:07:11 UTC