Re: Using ARIA in HTML

Hi Josh, many thanks will diegst and process feedback!

On 4 July 2012 11:14, Joshue O Connor <joshue.oconnor@cfit.ie> wrote:

> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html