W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: ISSUE-96 Change Proposal

From: Matt May <mattmay@adobe.com>
Date: Thu, 1 Apr 2010 10:16:45 -0700
To: Shelley Powers <shelley.just@gmail.com>
CC: Maciej Stachowiak <mjs@apple.com>, Steven Faulkner <faulkner.steve@gmail.com>, Jonas Sicking <jonas@sicking.cc>, HTMLWG WG <public-html@w3.org>
Message-ID: <FBDDE8AF-562B-48C8-872E-1468DA9B9664@adobe.com>
On Apr 1, 2010, at 11:22 AM, Shelley Powers wrote:
>> This point is worth noting. Appropriate semantic markup for application
>> controls does not mean extra work has to be done by a screen reader or other
>> assistive technology, as Shelley suggested. Rather, the browser engine
>> directly exposes such controls to the appropriate accessibility API, and the
>> screen reader at the other end doesn't even have to know if it's a real
>> control or ARIA.
> That's all well and good, but it's still a bad design choice.
> How many declarative elements will we have in the future. Dozens?
> Hundreds? How many versions of HTML we'll we have to have, because we
> have to roll out new versions for a bunch of widgets that could be
> created with JavaScript and CSS?

A good language framework should evaluate what is being done thousands of different ways, and integrate those features as it evolves. If I had to write a date picker from the scraps that HTML 4.01 gives me each time for the whole rest of the web's existence, as a developer I'd want to tear what was left of my hair out.

One thing I think everyone here can agree upon is that when it comes to interactive web applications, HTML 4.01 is not expressive enough. That's why a lot of us are here. However, adding elements to make it more expressive is not necessarily a slippery slope to hundreds or thousands or millions of declarative elements. The ideal number of elements or classes in a language is "enough, but not too many." I'd say that if every major JS framework has a component that represents an elephant riding a unicycle, the HTML WG should at least consider whether it's worthwhile to add that to the language, and figure out how to generalize it, style it, and express its semantics across modalities.

If we have thousands of different implementations of date pickers, we have a nearly impossible task to make all of those implementations accessible using ARIA. If, however, we declare one color picker in the language, and define the rules around that one (especially if we throw in the amazing variations across nations and cultures around just what constitutes a date), then we only have one target to make accessible. It's a question of whether we make it technically possible to make something accessible if you try, or if we have an accessible control available as the laziest possible solution, and hope to catch low-skilled web devs just doing their job.

> See, developers, all that work you're doing with ARIA now? Like that
> stuff that AOL is paying for? Well, it's only _temporary-. Because we
> don't think you'll use it...even thought evidently, you are.

Where "you" is some extremely small subset of JS tools and developers who are actually doing ARIA today, you're right. And that, in a nutshell, is the problem. ARIA only solves problems when a developer has actively done the work, and simply put, the average web dev, for reasons various and sundry, cannot be depended upon to do that work.

ARIA is only intended to be a bridge from where we are today, with more JS frameworks than one can count, to some point in the future, where the HTML stack has caught up with the needs of the developer. It should only need to be used when authors come up with something that the browser doesn't have a built-in capability to express. It should continue to exist primarily in that capacity indefinitely, so that people can do more for accessibility than what is built into the browsers of the day. And as far as jQuery et al. goes, I would expect that they will wean themselves off of things like date picker controls and so on from scratch as HTML5 support is ready to do the job, too.

Received on Thursday, 1 April 2010 17:17:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:00 UTC