Re: Drop longdesc, get aria-describedat?

Quoting Silvia Pfeiffer <silviapfeiffer1@gmail.com>:

>>> > So, the process is the reason we can't say 'use @aria-describedat' ...
>>
>> Heavens, no!
>>
>> Explain to me, if you think the process is at fault, why we should drop
>> everything currently in process to create a substitute for  
>> something that already exists. Please explain this wisdom, because  
>> it sounds like folly to me.
>
>
> It is the reason you brought up. So, if you don't mind, could you
> explain the process that you foresee for the introduction of
> @aria-describedat and how long it will take before we get such a
> specification?
>

Hi Silvia,

There is "Process" and then there is process, and it is the second  
"small P" problem I think we are grappling with. At issue is that it  
takes considerably longer to get robust support for new additions to  
accessibility accommodations, in part because there are more than just  
a hand-full of browser engineers involved. The process of speccing out  
a new attribute, of getting it deployed, tested and then "spreading  
the authoring word" so that it starts to get up-take takes time,  
sometimes a long time. There are also a plethora of AT tools  
(including numerous screen readers) which also need to 'catch up' to  
the spec/standard - and we are still seeing tools just now starting to  
adopt ARIA. However unlike some of the newer features of HTML5 that  
have spotty support across browsers today ("Best viewed in Chrome"  
anyone?), which simply means that some users cannot take advantage of  
wowser features today, it's no big deal for most users. For example, I  
am sympathetic to a point with the current thinking of some members of  
the CSS Working Group to start adopting -webkit- prefixes even if they  
are not webkit based browsers (although I disagree with their  
position), but truthfully, while I appreciate 'artistic concerns"  
here, they pale to accessibility concerns (at least for me).

When it comes to ensuring access for persons with disabilities, the  
cost-of-failure bar is significantly higher, and before we obsolete  
@longdesc we have a long road to hoe to get a functional replacement  
in place. That process, the one that includes time as a major  
component, is why rushing pell-mell to get something in place "RIGHT  
AWAY!" fails our end users. Then there is the question of backward  
compatibility - a huge problem with real consequences (beyond rounded  
corners not rendering :) ) For example, in the real world I work in, I  
need to continue to support IE 8, simply due to the fact that Windows  
XP cannot upgrade beyond that, and ARIA support in IE8 is quite  
lacking. (And for those who are going to respond along the lines of  
"they need to upgrade", we *cannot* just tell disadvantaged users to  
completely upgrade their perfectly serviceable system because HTML5  
wants to toss our older technology in favor of the new and shiny -  
that doesn't cut it. Again, it will take time, and that will happen  
organically).

ARIA 1.1 is already envisioned as being a fairly short life-cycle  
Process (with the big P Process), but I honestly believe we need to  
forcefully de-link any new ARIA attribute from the @longdesc  
description now. It is unhelpful and frankly misleading.

JF

Received on Thursday, 8 March 2012 01:56:56 UTC