Re: ISSUE-96 Change Proposal

Also this seems a little chicken and egg. While a more busy  
declarative markup language may not be ideal and bridging technolgies  
like ARIA end up being necessarily more permanent, taking the toolkit  
intoto means that deva have more tools and users potentially more  
accessible and usable interfaces.

Again, sorry for top posting.

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:46:25 UTC