[Bug 22090] New: feedbck from James Craig part 2

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

            Bug ID: 22090
           Summary: feedbck from James Craig part 2
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Using ARIA in HTML
          Assignee: faulkner.steve@gmail.com
          Reporter: faulkner.steve@gmail.com
        QA Contact: dave.null@w3.org
                CC: mike@w3.org, public-html-bugzilla@w3.org

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Saturday, 18 May 2013 16:07:18 UTC