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

Um, this is a bit problematic because the comment didn't come from the
original commenter. If we were to process this formally as a public
comment, it could surprise the message originator. Also the practice of
forwarding messages from other lists opens a back door to our comment
process, and makes it harder to define and defend the distinction
between "public comments that we are obligated to process formally" and
"other things that have hit the radar".

You're welcome to process editorial aspects of this comment at your own
discretion, and raise substantive aspects as part of the normal WG
process. But if you think this should be processed as a public comment,
please ask the original message originator to forward a copy to the
public comments list themselves (a request they are free to decline). It
is important that all public comments be directly traceable to and
intentionally submitted by the actual commenter.

Michael

James Craig wrote:
> Editorial comments from 'timeless@gmail.com <mailto:timeless@gmail.com>'
>
> Begin forwarded message:
>
>> Resent-From: w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>
>> From: timeless <timeless@gmail.com <mailto: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 <mailto: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".
>>
>

-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>

Received on Thursday, 14 October 2010 18:38:37 UTC