[Bug 22089] New: feedbck from James Craig part 1

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

            Bug ID: 22089
           Summary: feedbck from James Craig part 1
    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

Comments on the March 2nd draft. Some of this is editorial. Some is
substantive. Please let me know if you'd prefer I enter individual items in
Bugzilla. — James

The quoted bits are verbatim from the document, followed by my comments.

> For example if using role=button the element must be able to recieve focus and a user must be able to activate the action associated with the element using both the enter and the space key.

Enter and Return are not entirely interchangeable. The appropriate key on Mac
is Return. I think you can just change "enter" to "enter/return" here, but you
might want to note the platform difference. Also "receive" is misspelled.

> Note: Any elements that are not required children of the element with a role=presentation keep their semantics. This includes other elements with required children.

Suggest appending: …such as nested lists or nested tables.

> Currently aria-labelledby and aria-describedby are more robustly supported for associating text content to a subset of interactive content elements, they do not work correctly on links, support on embedded content is unknown, but can be safely used on form controls including the many input types.

W3C docs should never state something "does not work" as the expectation is
that this will change. Instead say something like, at the time of this writing,
and then ideally have a list of blocking bug links. A reader can then
cross-reference the links to know if the restriction is still relevant.

> In Internet Explorer, if you use aria-labelledby with multiple id references or aria-describedby with single or multiple id references, the referenced elements must be what Microsoft terms as accessible HTML elements.

This is another place to list a blocking bug number if one is available.

> You do not use it if a set of controls only contains these widgets…

Pronoun-itis: Consider changing to, "You do not use role="application" if a set
of controls only contains these widgets…"

> This also applies if you mark them up and create an interaction model using WAI-ARIA roles instead of standard HTML widgets:
>
>       • text box.

There should probably be a note somewhere in the document that indicates it's
not recommended that authors develop custom text input widgets. It's almost
always best to use the native inputs for these.

> dialog and alertdialog. These cause screen readers to go into a sort of application mode implicitly once focus moves to a control inside them.


Please note that this is *some* screen readers, not all.

There should probably also be a note in the document that indicates how one
should be able to include static non-interactive content in a dialog by using
the document role to counteract the application mode. To my knowledge, static
dialog content can only be accessed in Safari with VoiceOver. I believe the
Windows screen readers disallow access to any static content in dialogs,
whether or not the application mode is used. I consider this to be a bug,
though not everyone agrees.

> You only want to use role=application if the content you’re providing consists of only interactive controls,

"only interactive controls" should probably be "only focusable, interactive
controls"

> be it FaceBook posts and comments

s/FaceBook/Facebook/

> We primarily still deal with documents on the web, even though they may have a desktop-ish feel to them on the surface.

While I appreciate you not overcapitalizing when "web" is used as an adjective
("web page", "web browser"), this is actually one of the only places "web"
should be capitalized, because it's used as a proper noun: "the Web"

Note: Same goes for "internet." You would not capitalize "internet domain" but
you would capitalize "domain on the Internet."

> NEVER put it on a widely containing element such as body if…

Pronoun-itis: Consider changing to, "NEVER put role="application" on a widely
containing element such as body if …"

> Recommended ARIA usage by HTML language feature

This table would be more useful printed with a "thead" (Note: I print when I
edit.)

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

Received on Saturday, 18 May 2013 16:05:53 UTC