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

On Wed, Oct 21, 2009 at 9:48 AM, Steven Faulkner
<faulkner.steve@gmail.com> wrote:
> Hi Thomas,
>
> firstly i would like to bring the topic back to the specifics I detailed in
> my first email.
> This is about the overiding of the a elements native role.
>
> I really think that each of the 60 odd element/type definitions in the table
> needed to be discussed peicemeal at least initially and what is most
> appropriate for one element or element type (widget, structural etc) may not
> be appropriate for another.

I think, too, we need to be careful about over-specifying in the HTML5
document.

Here's a likely scenario where we would want to use a role of "button"
for a link.

We have a web page with three links, all three styled like buttons.
There is nothing invalid in this. In fact, it has been an encouraged
use of CSS.

The "buttons" are labeled Prev, Next, and Home, and are used to
traverse through a set of slides (containing web page content, images,
whatever).

If scripting is disabled, the "buttons" are hypertext links that open
another web page when clicked. If scripting is not disabled, though,
the link behavior is overridden, and the next slide is updated via the
use of Ajax. I say overridden, but technically, clicking the button
still opens external content -- just not in the typical way.

In the first use, the links are allowed to exercise their default
linking behavior, but in the second use, they're treated as buttons.
Perfectly acceptable behavior, and not uncommon, either.

Now, the documentation for this app states that to traverse through
the slides, click the Prev and Next button. To return to page 1, click
the Home button. That's because the link looks like a button, and in
the expected, default circumstance, acts like a button.

Now, I suppose one could embed links that look like links in the web
page, and then if scripting is enabled, replace the navigation with
buttons, and then in the documentation go through a lot of folderol
that if scripting isn't enabled, click the _links_ but if scripting is
enabled, click the buttons. But few are going to do this, because it's
painfully anal and obtuse.

So, whether a link is used or not, the navigation item is styled like
a button, and in the developer's viewpoint, acts like a button -- even
when the default linking behavior is used.

Do we really want to tell people that a) they can't style links as
buttons, and b) can't use links as script-enabled buttons? I hope the
answer is no, because this there has been an entire herd of big darn
angus cows who have trod this cow path. You'd have to close your eyes
and hum Beatles tunes not to see that is common usage and behavior.

Why then, with something so common, so accepted, can we not add the
last finishing touch, and give these "buttons" a role of button?

Shelley



>
>  >If they set it by script, it won't be testable by a validator either.
>
>  people do and will run the HTML5 validator against the DOM of a page, in
> this case ARIA implemented via scripting will get picked up. It makes sense
> to have a tool that checks ARIA conformance  dynamically rather than from a
> static view.
>
> as an aside: I would advise that all ARIA widget roles, states and
> properties that are dependent on scripting be added via scripting, that way
> if scripting is not available the non functioning ARIA stuff is not
> littering the code.
>>Should the first paragraph above (faux heading) be conforming if
>>role=heading is set? (as written above, it is non-conforming because
>>"The p element should not be used when a more specific element is more
>>appropriate.", and <hN> or <hgroup><h1> is a "more specific element"
>>for a heading)
>
> in the case of headings as in other cases, the only signal that this is
> being used as a heading is the role value, if that is taken away not a peep
> from the conformance checker. But in this case I think it would be
> appropriate to have a warning advising the use of a <hx> element is better.
> I cannot myself think of a reason why one would not use a <hx> element over
> a <p role="heading">.
>
>>> If they are _able_ to do this without conformance errors
>
>>...flagged by a validator, which doesn't mean it is conforming.
>
> as I have stated, I am talking about testable conformance errors...
> I have no problem with the spec saying authors should not overide an
> elements native semantics, but if the ayhtor does it's OK to convey the
> resulting role and behaviour to AT via ARIA.
>
>>Oh, and, how about flagging <a href="javascript:..."> as an error? (or
>>at least a warning), as it's hardly a "link"
>
> that is an issue apart from what we I am discussing, but i suggest you
> report it as a bug, it sounds like a good idea.
>
>
> regards
> steve
> 2009/10/21 Thomas Broyer <t.broyer@ltgt.net>
>>
>> On Wed, Oct 21, 2009 at 2:08 PM, Steven Faulkner wrote:
>> > hi Ian,
>> >
>> >>> I agree, but developers are allowed to add behaviours and styles that
>> >>> turn a link into a button
>> >
>> >>Technically, they're not.
>> >
>> >
>> > OK , but practically they are and do.
>> >
>> > putting it another way:
>> >
>> > developers are _able_ to add behaviours and styles that turn a link into
>> > a
>> > button.
>> >
>> >>> 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.
>> > The reason why is immaterial, it still results in the same outcome,
>> > pseudo
>> > widgets are created without issue, but if they add ARIA to make them
>> > accessible they nagged about improper use of ARIA in HTML5.
>>
>> Is this really different from those examples (feel free to move the
>> CSS out of the style="" attribute and into a stylesheet, with any
>> selector that'd then match the following elements):
>>   <p style="font-size: 24pt; font-weight: bold">This is a heading</p>
>>   <p>Let <em>x</em> and <em>y</em> be the trains' speed, in mph</p>
>>   <p>I am <span style='font-style: italic'>not</span> a number!</p>
>>
>> (note how <em> was used instead of <var>, and <span style="font-style:
>> italic'> instead of <em>, which can be because the author used a
>> WYSIWYG editor, such as a <div contenteditable=true>, as can be found
>> in many CMSes and blogs)
>>
>> Should the first paragraph above (faux heading) be conforming if
>> role=heading is set? (as written above, it is non-conforming because
>> "The p element should not be used when a more specific element is more
>> appropriate.", and <hN> or <hgroup><h1> is a "more specific element"
>> for a heading)
>>
>> > If they are _able_ to do this without conformance errors
>>
>> ...flagged by a validator, which doesn't mean it is conforming.
>>
>> > it follows that
>> > they should be able to add ARIA without conformance errors.
>>
>> If they set it by script, it won't be testable by a validator either.
>>
>> > reducued accessibility should not be the end result of testable
>> > conformance
>> > criteria.
>>
>> Such as <img alt="the validator said I must add this attribute" src="...">
>> ? ;-)
>>
>> (otherwise, I was about to write what Lars Gunther said, and he said
>> it much better than I'd have)
>>
>> Oh, and, how about flagging <a href="javascript:..."> as an error? (or
>> at least a warning), as it's hardly a "link" (if you want <a
>> href="javascript:top.frames['other'].location.replace('something.html')">
>> you should rather use <a href="something.html" target=other
>> onclick="top.frames[this.target].location.replace(this.href)"> or
>> <span role=link
>>
>> onclick="javascript:top.frames['other'].location.replace('something;html')">)
>>
>> --
>> Thomas Broyer
>> /tɔ.ma.bʁwa.je/
>
>
>
> --
> with regards
>
> Steve Faulkner
> Technical Director - TPG Europe
> Director - Web Accessibility Tools Consortium
>
> www.paciellogroup.com | www.wat-c.org
> Web Accessibility Toolbar -
> http://www.paciellogroup.com/resources/wat-ie-about.html
>

Received on Wednesday, 21 October 2009 16:43:19 UTC