RE: few more questions/comments re: your ATAG responses

My answers marked with "JR".



A.2.2.1 4th bullet - I still think we need to have a more formal definition/understanding of what "status information" is - specifically what is or is not status information..



JR: OK, I couldn't think of a better definition than the circular "information that indicates state"...so maybe the SC should be reworded:

A.2.2.1 Access to Status Displays: If an editing-view highlights parts of the content being edited to indicate information about the content (e.g. an underline indicating a spelling error), then the information being indicated can be programmatically determined.

Ed. Not a substantive change.





A.2.2.2

1st bullet - I think we need a clear distinction of what is or is not a text property..



JR: OK - see below.





Additional Note - Do we mean just one text property or all text properties



JR: We mean all  - see below.





2nd bullet - I still think the SC needs to refer to a requirement for the authoring tool (not a

requirement for the text property..)



JR: OK - see below.





4th bullet -  we need to distinguish between the cases of an authoring tool intrinsically not being able to communicate a text property by design and an authoring tool having the capability but not doing it..



JR: (1) Reword A.2.2.2 and (2) move platform service exception to the definition:

A.2.2.2 Access to Text Formatting Properties: If an editing-view renders any text formatting properties that authors can also edit using the editing-view, then the properties can be programmatically determined.

Ed. Not a substantive change.



"- Communication between the authoring tool and assistive technology: For non-web-based user interfaces, this means making use of platform accessibility services, APIs, and in some cases document object models. For web-based user interfaces, this means ensuring that the user agent can pass on the information (e.g. through the use of ARIA)."

- NOTE: All of the success criteria requiring programmatic determinability via a platform accessibility service are all contingent on whether a platform accessibility service is present for the platform and whether the platform accessibility service is capable of supporting the required communication.

Ed. Not a substantive change as this would already have been judged not applicable.





A.3.1.2

1st bullet (a) -are there other techniques (ways) to test a) other than "press ENTER and see which component takes it" - what happens if authoring tool doesn't support "press ENTER.." or doesn't have "components"..? for example..



JR: Inspection tools such as Inspect.exe on Windows can be used. I really don't think this is an issue.





also I would like to see more discussion on objective testability of "known location".. what if it is not possible for the author to "know ahead of time" and/or there is no documentation of keyboard command in authoring tool..objective testability of "known location" - known by whom/when - is it possible to be more specific here?



JR: PROPOSAL: Change "known location" to "documented location"

Ed. Not a substantive change.





Cheers,

Jan







--
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://idrc.ocad.ca/
Faculty of Design | OCAD University

From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On Behalf Of Boland Jr, Frederick E.
Sent: July 21, 2011 2:13 PM
To: w3c-wai-au@w3.org
Subject: FW: few more questions/comments re: your ATAG responses

Forwarded to list..

From: Richards, Jan [mailto:jrichards@ocad.ca]
Sent: Thursday, July 21, 2011 12:20 PM
To: Boland Jr, Frederick E.
Subject: RE: few more questions/comments re: your ATAG responses

Hi Tim,

Do you mind sending these to the list? So then they have a URI.

-Jan

--
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://idrc.ocad.ca/
Faculty of Design | OCAD University

From: Boland Jr, Frederick E. [mailto:frederick.boland@nist.gov]
Sent: July 20, 2011 3:43 PM
To: Richards, Jan
Subject: few more questions/comments re: your ATAG responses

-- I'm getting to these a little at a time..

A.2.2.1 4th bullet - I still think we need to have a more formal definition/understanding of
what "status information" is - specifically what is or is not status information..

A.2.2.2
1st bullet - I think we need a clear distinction of what is or is not a text property..
Additional NOte - Do we mean just one text property or all text properties
2nd bullet - I still think the SC needs to refer to a requirement for the authoring tool (not a
requirement for the text property..)
4th bullet -  we need to distinguish between
the cases of an authoring tool intrinsically not being able to communicate a text property by
design and an authoring tool having the capability but not doing it..

A.3.1.2
1st bullet (a) -are there other techniques (ways) to test a) other than "press ENTER and see which component
takes it" - what happens if authoring tool doesn't support "press ENTER.." or doesn't have "components"..?
for example..
also I would like to see more discussion on objective testability of "known location".. what if it is not
possible for the author to "know ahead of time" and/or there is no documentation of keyboard command in authoring tool..
objective testability of "known location" - known by whom/when - is it possible to be more specific here?

Will send more later..
Thanks and best wishes
Tim Boland NIST