[Bug 17691] New: General Editorial Comments

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17691

           Summary: General Editorial Comments
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Using ARIA in HTML
        AssignedTo: faulkner.steve@gmail.com
        ReportedBy: joshue.oconnor@cfit.ie
         QAContact: dave.null@w3.org
                CC: mike@w3.org, public-html-bugzilla@w3.org


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 things are presented. The "Notes on
ARIA use in HTML" for example would be 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 but rewording.
Take the link "add those yourself" the context is in the previous sentence,
(unless you add some ARIA or course ;-))

The section "Add ARIA inline or via script?

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

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, they need to be made a little clearer.  If
they are the same 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, 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?).

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 4 July 2012 10:08:21 UTC