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

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.

 >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