Re: ISSUE-96 Change Proposal

Big + 1 to a lot of Matts comments below. Apologies for top posting btw.

On 1 Apr 2010, at 18:16, 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.  
> 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.
>
> -
> m

Received on Thursday, 1 April 2010 19:42:28 UTC