Re: More (Was: Some feedback on "Using WAI-ARIA in HTML" document)

thanks for the feedback James, much appreciated! I have created bugs for
the 2 emails worth and have added you to the cc list of the bugs

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>


On 1 May 2013 00:36, James Craig <jcraig@apple.com> wrote:

> Starting with the "Recommended ARIA usage" table:
>
> > dl
>
> Please note that there is no direct ARIA role match for description lists,
> so it's in appropriate to override the native role in this case unless the
> author is retrofitting an improper use of the DL element.
>
> > hgroup
>
> Probably need to remove this.
>
> > iframe
>
> Probably need to add another row for iframe[seamless], where it is okay to
> override with any general grouping role.
>
> > input type=checkbox
>
> This note is no longer relevant for ARIA 1.0: "it is required that an
> explicitrole=checkbox is declared "
> The host language implicit role is enough without the redundant role
> attribute.
>
> > input type=number
> > input type=range
>
> Should add that it's okay to use aria-valuetext on these, with or without
> an explicit role.
>
> > math
>
> Why is it recommended to use the ARIA role here? The ARIA role is mainly
> useful for math that is not marked up in such a way as to be
> programmatically determinable. MathML on the other hand, provides enough
> structure and metadata to determine much more information about the math
> content. I would say that it is not necessary or recommended to explicitly
> use a math role on MathML.
>
> > meter
>
> This one is listed as N/A, but I think progressbar is the equivalent role
> here. I would still list this as NO, though.
>
> > ol
>
> Add "group" to the role list.
>
> > output
>
> Not YES. I'd say it DEPENDS. If you add role="status", it will force this
> to be a broadcasting live region. In some cases, this is fine, but if this
> is an element whose value changes constantly due to scripted updates rather
> than explicit user action (like a progressbar), it'd be more appropriate to
> set aria-live="off". Otherwise some AT users are going to find this very
> distracting, even impossible to use. Even "polite" live regions can be
> annoying if they are overused.
>
> > progress
>
> Should add that it's okay to use aria-valuetext on this (e.g. "Step 2 of
> 10"), with or without an explicit role.
>
> > tbody, thead, tfoot
>
> Change "NONE" to "role=rowgroup"
> Change "N/A" to "NO"
> Change "these elements" to "these unrendered elements."
>
> > Text level elements not listed elsewhere
>
> Out of curiousity, why weren't INS and DEL listed here instead of on their
> own row?
>
> > Element with an inert attribute
>
> Change "aria-disabled" to "aria-hidden"
> Change "NO" to either "YES" or "DEPENDS."
>
> Remove the note about disabled content and add a new note indicating that
> inert content is used for things like the background contents while showing
> a modal dialog. In this case, it would be appropriate and recommended to
> use aria-hidden="true"… If there are cases where inert is being used to
> deactivate foreground content that is still intended for consumption,
> @inert should be combined with an explicit aria-hidden="false" to override
> the default rendering engine behavior.
>
> > Element is focusable
>
> I think you should split this into a couple rows.
>
> 1. Focusable elements that are natively focusable (links, buttons, etc.)
> NO, don't override.
> 2. Focusable elements that are not natively focusable (li, span, div,
> etc.) YES, override with any widget role.
>
> For example, <span tabindex="0"> is focusable but has no role in most
> rendering engines. The document has "NONE" in the role column, but I think
> it needs a role here in a lot of cases.
>
> > Element that is a candidate for constraint validation but…
>
> The note column should be updated to link to what HTML defines what
> constitutes the user has interacted with the control "significantly." Also
> ARIA defines aria-invalid="grammar" and aria-invalid="spelling" which are
> not mentioned here.
>
> ---
>
> That's all I noticed. Great document! Thanks for publishing it.
>
> James
>
>