Re: Accessible Rich Internet Applications (WAI-ARIA) 1.0

http://www.w3.org/TR/2010/WD-wai-aria-20100916/complete

You use both "a user" and "the user" in this document, it might be the
case that "the user" should be used in all instances.

> alertdialog
>    A type of dialog that contains an alert message,
> where initial focus goes an element within the dialog.

s/an/to an/

s/Also see/See also/g

> 6.2.4. Value
> tristate
>    Value representing true or false, with an intermediate "mixed" value

What's the default?

> aria-busy (state)
>    Indicates whether an element, and its subtree, are currently being updated.

I think you should write "an element (and its subtree) is ".

> aria-flowto
>    Identifies the next element (or elements) in the recommended reading order of content,
> overriding the general default to read in document source order.

s/to read/of reading/

> aria-multiline
>     Indicates whether a text box accepts only a single line, or if it can accept multiline input.

   Indicates whether a text box accepts multiple lines of input or
only a single line.

> aria-relevant
>     Indicates what user agent change notifications (additions, removals, etc.)
> assistive technologies will monitor within a live region. Also see aria-atomic.

s/will/should/ or s/monitor/receive/ ?

> aria-activedescendant (property)
> Authors SHOULD ensure that the currently active descendant remains visible and in view.

I know you're using SHOULD and not MUST (thanks), but I'd like to note
that if the user tries scrolling the page to see other content, it
isn't necessarily proper (or in fact is probably absolutely wrong) for
the page to fight the user.

FWIW, DOM mutation events are incredibly expensive, so I'd be glad to
see any suggestions relating to them be dropped. Turning on
accessibility in gecko incurs an immediate performance penalty because
of things like that.

> aria-autocomplete (property)
> Indicates whether user input completion suggestions are provided.
> For a textbox with the aria-autocomplete attribute set to either inline or both
>, authors SHOULD ensure that the auto-completion text is selected
> and comes previously typed character, so the user can type over it.

"and comes previously" doesn't work.

> aria-checked (state)

> The mixed value is not supported on radio or menuitemradio or any
> element that inherits from these in the taxonomy, and user agents
> MUST treat a mixed value as equivalent to false on those roles.

s/on those/for those/

> Values of aria-dropeffect
> Value Description
> move: The source object will be removed from its original location and dropped into the target.

s/original/current/

original would be wrong if it has been moved previously

> popup:        There is a popup menu or dialog that allows the user to choose one of the drag operations (copy, move, link, execute) and any other drag functionality, such as cancel.

It's probably too late, but "choice" would have been better. The word
"popup" gives too much of a hint to designers who should be free to
implement choice however they like....

> aria-flowto (property)
> When aria-flowto has a single IDREF, it allows assistive technologies to,
> at the user's request, forego normal document reading order and go to
> the targeted object. aria-flowto in subsequent elements would follow a
> process similar to next focus in XHTML2 ([XHTML])

As XHTML2 and friends are rather dead, is this a good thing to reference?

> In the case of one or more IDREFS, user agents or assistive technologies
> SHOULD give a user the option of navigating to any of the elements targeted.

s/elements targeted/targeted elements/

> aria-relevant (property)
> When text changes are denoted as relevant, user agents MUST monitor any descendant

a MUST is rather strong. Could it be a SHOULD?

> If a CSS selector includes a WAI-ARIA attribute (e.g. input[aria-invalid="true"]),
> user agents MUST immediately update the visual display of any elements
> matching (or no longer matching) the selector any time the attribute is
> added/changed/removed in the DOM.

I'm not sure MUST + immediately is appropriate, if i'm doing split
process rendering, then the paint cycle may not be "immediate", it
will be "soon" and "before js can detect that it wasn't done".

Received on Thursday, 14 October 2010 09:49:06 UTC