Re: ARIA roles added to the a element should be conforming in HTML5.

On Thu, 22 Oct 2009 16:42:50 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

> On Thu, Oct 22, 2009 at 9:32 AM, Leif Halvard Silli
> <xn--mlform-iua@xn--mlform-iua.no> wrote:
>> Tab Atkins Jr. On 09-10-22 16.13:
>>> On Thu, Oct 22, 2009 at 9:08 AM, Leif Halvard Silli wrote:
>>>>
>>>> In the spirit of "don't break the Web", the most important question  
>>>> seems to me be to be "should it work?" Should a <h1> with a
>>>> role="button" be presented as a button in accessibility devices?

[a few people with known expertise and experiences in accessibility said  
Yes. I agree with them.]

>>> You can't break the web unless a particular practice is already
>>> widespread and changing the current behavior for it would be
>>> detrimental to sites relying on the current behavior.
>>>
>>> Are there a significant number of sites currently using <h1
>>> role=button> and expecting it to be presented as a button to ATs?  Are
>>> there ATs who *do* present it as such?
>>>
>>> Both of those have to be true before "don't break the web" becomes
>>> relevant.
>>
>> I agree that those questions are relevant. But one could just as well  
>> turn them and say: "Do you want to forbid aria="button" on a <h1>?
>> Well, then you should first check that no sites do this, and that no
>> user agents support it!"
>
> Well, since aria just recently got put into HTML, I suspect it's not
> widely used yet.  (I'm asking around for possible evidence.)

Suspicion is not proof. ARIA has been around for a long time (longer than  
HTML5, for example) and included in HTML content whatever the spec said  
before (through various Javascript libraries and products from and for  
large organisations, as noted elsewhere in the thread).

Some user agents, and some assistive technologies, already support ARIA. A  
3-minute test case

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html dir="ltr">
<head>
  <title>Blank page</title>
</head>
<body><h1 role="button">test</h1>
<button>test</button></body></html>

running in Opera 1010 Mac (last week's weekly[1]) with VoiceOver suggests  
that the role works on H1 now. As Steve and others said it should. Using  
role="button" on a link behaves that way too.

In any case, as a browser implementor I will strongly resist attempts to  
get the browser to behave differently in this case - since our goal is to  
help users.

I have been told various times that HTML 5 is about what happens in the  
real world (indeed, I promote that benefit consistently in my mnay talks  
on the topic), but I am ready to see the evidence.

>> The spirit of "don't break the Web" is "don't destroy the experience  
>> for the user because of some principle".
>
> Yup, but in the absence of evidence, you might as well go with the
> principle.  If evidence shows up later, you can always change things.

Well, there are multiple conflicting principles here (as usual).
...
>> Why should ARIA work any different from CSS?
...
> Because ARIA and CSS are different things.  Why should they work
> similarly?  ARIA is nothing than a patch to help out users of ATs when
> authors use elements in novel ways, such as using <div>s to implement
> sliders.  It's not meant as a general tool to be used by the average
> author - with luck, a normal author never has to get anywhere *near*
> ARIA, because they're using elements for what they're intended for.

So it's a patch for authors who do crazy things. In which case the  
expected use is where authors don't do the right thing. If you make that  
non-conforming, you can already argue that your authors don't care about  
the semantics of conformance anyway, perhaps just the yes/no status. I am  
not sure how you get from there (with or without the last assumption) to  
"ARIA shouldn't be conforming where it is used in ways that match its use  
cases and what authors actually do".

> As well, it's really just more trouble than it's worth to restrict CSS
> to only apply 'conforming' styling - the operations are too low-level
> to sanely constrain.  ARIA, on the other hand, is a high-level tool
> that *can* be sanely restricted.

Perhaps, for some definition of "sane" that includes "don't worry what it  
is meant to achieve".


On Wed, 21 Oct 2009 13:20:08 +0200, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 21 Oct 2009, Steven Faulkner wrote:
>>
>> I agree, but developers are allowed to add behaviours and styles that
>> turn a link into a button
>
> Technically, they're not.
>
>> and they won't get nagged when they check the conformance of the code
>
> That's true, but only because it's nigh on impossible far validators to
> check this.

And as I interpret the priority of constituencies, it makes no sense to  
specify something that is easy but doesn't appear to lead to helpful  
behaviour, just because the right thing is nigh-on impossible for  
validators to get right. If we have to accept limitations of validators,  
then we have to accept the implications of those limitations in  
"downstream" work.


On Sat, 07 Nov 2009 10:13:26 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
>
> Do you have any reason to believe that we'll be more successful in
> asking authors to add a role attribute to the <a> than in asking them
> to change to use a more appropriate element?

Yes. We have seen companies like AOL and Yahoo! add ARIA markup to content  
whose semantic use is questionable (in part because the semantics of HTML  
are far less clear than we like to think). Stephane has explained a  
large-scale real-world use case for the same. One of the two major  
motivations for ARIA was to provie the ability to patch dodgy markup so at  
least it *behaved* right in the real world, and this was to meet  
real-world needs (stretching back a decade, when precursor technology was  
being deployed commercially by e.g. UBAccess) of authors who would create  
whatever looked nice in IE5, but then had a need to try and repair the  
accessibility.

By the same token, we have reason to believe that authors will *not* fix  
markup which is semantically dodgy, but looks right. Where possible,  
however, they will patch it invisibly. (Have a look at the various  
discussions of how to conform to WCAG for examples of this - I don't have  
numbers, because they are *very* labour-intensive to generate. You have to  
take my word that I am not making this up for fun, or we need to figure  
out how to get the research done).


On Sun, 08 Nov 2009 03:41:26 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
> On Sat, Nov 7, 2009 at 11:36 AM, John Foliot <jfoliot@stanford.edu>
>> We can't envision all uses that authors might dream up moving
>> forward: look at Bespin and Canvas - nobody really envisioned Bespin  
>> like use when Canvas was spec'd, yet here we are today.
>
> I'll note that what Bespin did is not valid HTML 5. The spec says:
>
> "Authors should not use the canvas  element in a document when a more
> suitable element is available"

And yet Bespin is held up as a poster child (it is an interesting example  
in boundary pushing). So the existence proof is that people will do things  
contrary to the way they "should" be done, and get props for it.

This argument boils down to "should it be non-conforming to use a known  
effective repair strategy?".

It is asserted that the problems being repaired are extremely difficult to  
detect, but that they *should* not happen (yet you are happy that Bespin  
conforms, doing something it *should not* do) - with no explanation of how  
to achieve that goal, and two decades of evidence that it is not easy to  
achieve.

I find it amazingly hard to conclude that a right answer to the question  
is "yes".


[1] http://my.opera.com/desktopteam/blog has weekly builds of Opera. Look  
in the archive if you want to chase a particular version.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 10 November 2009 14:42:09 UTC