Re: ISSUE-96 Change Proposal

On Thu, Apr 1, 2010 at 11:16 AM, Matt May <mattmay@adobe.com> wrote:
> 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.

HTML 4.01 was never meant to be "expressive", if I understand your use
of the term. Somewhere along the way, though, HTML the markup, became
HTML, the web application platform. When it became a platform, it no
longer was one component of a group of components that allowed us to
develop for the web. Which means that innovation now has to start, and
does stop, with HTML.

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

How many is enough, but not too many?

Some would say, well progress is needed and every library has it, but
you know, the a progress isn't used with most web applications, and
not ever library has it. Several of the UI libraries have it, but it's
typically split out and built on top of whatever is the underlying
framework.

By following this course, this ensures that if a web developer does
need the progress bar, they include the library, if they don't, it's
not included.

So, in this respect, progress doesn't meet the filter. Not everyone
needs it, most don't need it, and not every library has it. We
definitely don't need the meter.

So, who builds this filter? Who makes this decision? This is
universally needed, but that isn't? Or do we just toss it all in,
disregarding the cost to developers, and tool builders? Evidently the
progress bar was added because one person came into the WhatWG group
in 2004 and said "everyone needs it". And that was enough.

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

But you're putting the focus on the technology, rather than on the
developer. No matter how much stuff you build into HTML, at some point
in time, you're going to have to get the developer on your site.

No matter how much we think we know what people need now, we'll always
be behind if the approach we take is built-in widgets. Web developers
are crafty little devils.

And frankly? Many of us won't use the HTML built in controls, because
we have our libraries we like. We have our tools we like. We've
integrated these into our applications have little interest in ripping
out what we have, and replacing it with something that is inferior.

But, if you integrate ARIA into the innards of something like, say,
Yahoo's YUI, or jQuery UI, then we don't have to do _anything_ and our
stuff is accessible with the next upgrade of our libraries. Of course,
you'll say, well that's fine, but what about the libraries that don't
have ARIA?

I've been developing for the web, and writing about web development
for 15 years. Here's what I know about developers: folks are still
going to use these libraries. They're not going to stop using them,
just because HTML5 is now a competitor for their favorite libraries.
If what you give them isn't better, _they won't use it_.

Instead of downplaying ARIA, and joining with the W3C and the WhatWG
to package these "common" widgets into the HTML markup, we should be
continuing the momentum that we're seeing this year, and get web
developers to embrace ARIA. Now is the time, there's no better.

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

You all spent two years defending one attribute, summary, in HTML --
can't you apply that same persistence and diligence in supporting
something more important?

People are still using tables for layouts. It takes time, and
persistence, to get people to change. You can't give up if people
don't embrace a new concept in a few years.


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

Ten years ago, we couldn't do anything about accessibility. We were
told that the only accessibility we could build into our applications
was keyboard access and make sure they could degrade gracefully if JS
was turned off. There was no way of marking a "live" region, and even
if there was, it was extremely difficult to test, because JAWS and
Window Eyes are hard to figure out how to use, and come with all sorts
of constraints if all you want to do is test.

Now, though, we have NVDA and Firefox on Windows, and Voice Over on
the Mac. And we have these things from ARIA that when we use them,
they actually work! A few weeks back when I was writing a chapter
about ARIA for my JavaScript cookbook, I wrote in it how much fun I
was having, adding ARIA into just a regular form or other type of
application. It was _fun_ to code, it was _fun_ to test...because I
could.

I had a specification that told me what I could do, some online
tutorials provided examples of how to do it, and for the first time, I
could actually test it.

I was sold. And now you're telling me, this is nothing more than a bridge?

> -
> m

Shelley

Received on Thursday, 1 April 2010 18:00:28 UTC