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