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

Editorial comments from 'timeless@gmail.com'

Begin forwarded message:

> Resent-From: w3c-wai-ig@w3.org
> From: timeless <timeless@gmail.com>
> Subject: Re: Accessible Rich Internet Applications (WAI-ARIA) 1.0
> Date: October 14, 2010 2:48:33 AM PDT
> To: w3c-wai-ig@w3.org
> 
> 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".
>