Re: Using ARIA in HTML

James Craig wrote:
[...]
> Looks good. Thanks for putting this together.

Yes, it does. Well done. Some comments below - I filed them as a general 
editorial bug.

This is an impressive document. I would be a little concerned that some 
of it may be a little unclear for devs as to how they should use it - 
this could be improved by tweaking the order within which some things 
are presented. The 'Notes on ARIA use in HTML' section for example, 
would be really good introduction and maybe would be better placed at 
the top of the document.

Under the first rule of ARIA use - the 'circumstances' section should 
have the bullet item "If the feature is available in HTML but it is not 
implemented or it is implemented, but accessibility support is not." 
first IMO - as this is a big reason why many devs will use ARIA in the 
first place.

In the section 'Adding an ARIA role overrides the native role semantics' 
- maybe this should clarify by stating that it /only/ overrides the 
native role semantics and leave the the "behaviours, states and 
properties of the host element" intact. This is implied in the text but 
could be made clearer.

For example. In the section "What adding a role does not do?

Maybe it could be clearer that you are talking about "Adding an ARIA 
role does not change the behaviours, states and properties of the host 
element but only the native role semantics." - or similar.

I think the inline link context in some cases could be improved by 
rewording. Take the link "add those yourself" the context is in the 
previous sentence, (unless you add some ARIA or course ;-))

In the section "Add ARIA inline or via script?"

It states:

"If the ARIA role or aria-* attribute does not rely on scripting to 
provide interaction behaviour, then it is safe to include the ARIA 
markup inline. For example, it is fine to add ARIA landmark roles or 
ARIA labelling and describing roles inline. If the content and 
interaction is only supported in a scripting enabled browsing context, 
for example Google docs applications require JavaScript enabled to work, 
so it is safe for them to include the ARIA markup inline."

IMO this is a little confusing. It seems to say the same thing - that it 
is safe to add ARIA inline in both scripted/non-scripted environments. 
If this is the case, fine. If there are distinctions however they need 
to be made a little clearer.  If they are the same then changing the 
last sentence to "If the content and interaction is only supported in a 
scripting enabled browsing context, for example Google docs applications 
that require JavaScript enabled to work, it is also safe to include the 
ARIA markup inline."

The Excel SpreadSheet graphic seems a little random and when advising to 
add ARIA via scripting it would be good to either include an example in 
the doc of how to do that and/or a link to resource where you can find 
out more.

On 'ARIA Validation' it may be a good idea to add something along the 
lines of "these validation errors will often be in no way indicative of 
ARIA creating any real world accessibility issues or resulting in a 
negative user experience but are merely the result of automated 
validation tests that cannot accommodate ARIA accessibility annotations" 
- or similar.

In "Use of role=presentation" section it may be best to say:

"Adding role=presentation removes the role semantics from its parent 
element"  - sounds better than "the element it is on". Also it ties back 
to your previous point. If behaviors, states and properties are 
maintained - mention that here also as this ties back to your earlier 
point and will reinforce prior learning (as such).

I would change the example:

This:

<h1 role=presentation>text</h1>

becomes this:

<>text</>

because, are you suggesting this is desirable or something that a dev 
would do? I think give an example that represents a real use case - or 
better use case. This is partially because reading it does give the 
impression that adding ARIA role 'breaks' the parent element. I think 
this is down to the empty angle brackets (<>text</>). Maybe explaining 
the net impact of these <> in the doc would help? If it just means that 
the element is then parsed as a text string for example, then spell that 
out for the reader (in particular as they appear a lot later on in the 
document).

In the sentence" For elements with no required children, any elements 
nested inside the element with role=presentation preserve their 
semantics." it would be better to spell it out. What persevered 
semantics  - if state, properties etc then make that clear.

WRT "aria-labelledby and aria-describedby" we are working in the WCAG TF 
on ARIA techniques that may be useful here, when they are ready for 
prime time I'll let you know.

Finally, in the last section when you say "Abstract roles"

Do not use the following abstract roles as they do not do anything!"

It would be good to clarify what you mean (as the first question may be 
- why are they there, why do they exist etc?).

HTH

Josh

Received on Wednesday, 4 July 2012 10:15:25 UTC