WAI AU -- 11 Jun 2012

<Jan> Chair: Jutta Treviranus

<Jan> From: http://lists.w3.org/Archives/Public/w3c-wai-au/2012AprJun/att-0047/ATAG2-CommentResponses_20124010LC.html

GZ1

<Jan> Resolved: AUWG: The reference point is, implicitly, compared with tools that do not follow any of the requriements of ATAG 2.0. The suggested wording "Increase the accessibility of..." also has an implicit comparison point.

<scribe> scribe: jeanne

IBM1

Sueann: We need to add soemthing to scope

<Jan> ACTION: Jan to Write a note re: to A.1.1.1 that is explicit that browser accessibility will play a role in the accessibility of web-based user agents, and therefore UAAG will be relevant when choosing the browser on which to deploy. [recorded in http://www.w3.org/2012/06/11-au-minutes.html#action01]

<trackbot> Created ACTION-378 - Write a note re: to A.1.1.1 that is explicit that browser accessibility will play a role in the accessibility of web-based user agents, and therefore UAAG will be relevant when choosing the browser on which to deploy. [on Jan Richards - due 2012-06-18].

Jutta: Are we talking about just web based interfaces?
... I am concerned that the authoring tool developer would then choose a specific browser.

Jan: I don't want to do that.
... I also don't want to tie ATAG to UAAG 2.0 since UAAG is not as close to recommendation as we are .
... At this point, we cannot expand the scope without leaving last call.

IBM2

Jan: International standards are not going to provide the techniques for how to label a button, for example, where the platform accessibility standards will.

<Jan> "...Unless special circumstances exist (e.g., a document has been superseded, the platform has undergone major architectural changes), the listed resources should be assumed to be relevant to the platforms listed. Several general software accessibility guidelines are also referenced. It is acceptable to follow one of these general guidelines, because in most cases, the techniques for...

<Jan> ...implementing the general guidelines on a platform will entail the same platform level guidance contained in the relevant platform accessibility guidelines."

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-au/2012AprJun/att-0047/ATAG2-CommentResponses_20124010LC.html

<Jan> http://www.w3.org/TR/2012/WD-IMPLEMENTING-ATAG20-20120410/#sc_a122

<Jan> http://www.w3.org/TR/2012/WD-IMPLEMENTING-ATAG20-20120410/#sc_a121

Cherie: I am concerned that we use "guidelines" so often and the sentence should be broken into two.

Jan: There are many documents in the list, some are regulations, some guidelines, some checklists. We could drop the IBM checklist. Or we could call it 'guidance' instead of guidelines

<Jan> It is acceptable to follow one of these sources of general guidance, because in most cases, the techniques for implementing the general guidance on a platform will entail the same platform level guidelines."

Cherie: Do we need anything after "platform level guidance"? Is the last clause necessary?

Jutta "platform level requirements"

<Jan> It is acceptable to follow one of these sources of general guidance, and in most cases, the techniques for implementing the general guidance on a platform will entail following the same platform accessibility guidelines."

Jan: Is that enough to satisfy IBM?

Sueann: Yes, I think so.

IBM3

<Jan> Resolved: It is acceptable to follow one of these sources of general guidance, and in most cases, the techniques for implementing the general guidance on a platform will entail following the same platform accessibility guidelines."

Jan: I worked out the proposed phrasing with [not heard] in the ARIA group.

<Jan> @@AUWG: There are several points made in the comment:

Sueann: I have to take this back to the submitter and review it.

<Jan> Re: tying communication with platform accessibility services with programmatically determined, it is already tied by a reference to "platform accessibility service" in "programmatically determined".

<Jan> Re: "communicate with", vs "using": The Working Group feels that "using" is too vague and instead proposes: "Platform Accessibility Services: If the authoring tool contains non-web-based user interfaces, then those non-web-based user interfaces expose accessibility information through platform accessibility services."

<Jan> Re: "platform accessibility service": The Working Group is concerned that that term is too vague. The definition should make it clear that IAccessible2 is covered and in fact IAccessible 2 is an example.

<Jan> ACTION: Sueann to take response to IBM3 back to reviewer.\ [recorded in http://www.w3.org/2012/06/11-au-minutes.html#action02]

<trackbot> Created ACTION-379 - Take response to IBM3 back to reviewer.\ [on Sueann Nichols - due 2012-06-18].

IBM4 & IBM5 - A.2.2.1

<Jan> @@AUWG: It is not the "hidden elements", themselves, that are targeted by the success criterion, but rather status indicators placed into the authoring tool user interface by the authoring tool. For example, a WYSIWYG authoring tool might insert an icon to remind authors of the location of an anchor or a comment. The Working Group will clarify this with the following sentence in the intent:

<Jan> "The note provides some examples of status indicators that are relatively common in authoring tools. For example, many WYSIWYG editors include an option to display an icon to indicate the location of anchor tags and comments, both of which would otherwise be hidden from view. Another common status indicator is underlining spelling errors in red."

Jan: The main point is that we aren't targeting hidden elements, but rather that hidden elements could be drawn to the surface for editing. What we are saying is that "if they are drawn to the surface, they must be accessibly displayed."

Cherie: What about redacted elements, which are not supposed to be exposed to the user.

Jan: Do you mean redacted or show comments text, like in Word?
... In Word, it is an indicator to the author that the text exists, it has information content to an author, who may or may not chose to have it displayed.

Cherie: So we are talking about the display of content, not the accessibility of content itself.

Jan: Yes, but I am proposing changing the Intent to make it more clear.

<Jan> Resolved: @@AUWG: It is not the "hidden elements", themselves, that are targeted by the success criterion, but rather status indicators placed into the authoring tool user interface by the authoring tool. For example, a WYSIWYG authoring tool might insert an icon to remind authors of the location of an anchor or a comment. The Working Group will clarify this with the following sentence in...

<Jan> ...the intent: "The note provides some examples of status indicators that are relatively common in authoring tools. For example, many WYSIWYG editors include an option to display an icon to indicate the location of anchor tags and comments, both of which would otherwise be hidden from view. Another common status indicator is underlining spelling errors in red."

Jutta: than does this address the concern?

Sueann: Yes, I think it does.

<Jan> Resolved: AUWG: The Working Group agrees with the wording suggestion:

Jutta reads IBM5 to accept the IBM5 wording

<Jan> "If an editing-view adds status indicators to the content being edited, then the information being conveyed by the status indicators can be programmatically determined.

IBM6

<Jan> AUWG: This point was discussed at length within the group in light of the fact that most smart phones do in fact include keyboard control (iOS devices can be controlled by an external Bluetooth keyboard - http://support.apple.com/kb/HT4112, Android devices can be controlled with a D-Pad (or D-pad emulator), many BlackBerry devices include physical keyboards and support keyboard shortcuts)....

<Jan> ...The discussion led to the following note on A.3.1.1: "Note 1: Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. This success criterion does not imply the presence of a hardware keyboard."

Jan: Maybe something has to change in the t erminology, but these devices are taking keyboard input.
... perhaps the reviewer didn't read the entire section -- there are other ways to enter information in the devices - touch or gesture - but when you come down to it, keyboard is still enabled.

Sueann: That really isn't a gap. Should we state that assumption?

Jan: Even those the devices have test devices without a keyboard, so even though the basic mechanisms are in the platform, but it is being lost, because, for example, the developer may forget to code a focus indicator for the keyboard.
... we even added the safety net that if the platform won't support it, you can still claim conformance.

<Jan> Partial ATAG 2.0 Conformance - Platform Limitations (Level A, AA, or AAA): This conformance option may be selected when an authoring tool is unable to meet one or more success criteria because of intrinsic limitations of the platform (e.g., lacking a platform accessibility service). The (optional) explanation of conformance claim results should explain what platform features are missing.

<Jan> Resolved: AUWG: This point was discussed at length within the group in light of the fact that most smart phones do in fact include keyboard control (iOS devices can be controlled by an external Bluetooth keyboard - http://support.apple.com/kb/HT4112, Android devices can be controlled with a D-Pad (or D-pad emulator), many BlackBerry devices include physical keyboards and support keyboard...

<Jan> ...shortcuts). The discussion led to the following note on A.3.1.1: "Note 1: Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. This success criterion does not imply the presence of a hardware keyboard."

IBM7

Jutta: This is the same issue and discussion as IBM6.

Sueann: What is being done to fix WCAG?

<Jan> keyboard interface interface used by software to obtain keystroke input Note 1: A keyboard interface allows users to provide keystroke input to programs even if the native technology does not contain a keyboard. Example: A touchscreen PDA has a keyboard interface built into its operating system as well as a connector for external keyboards. Applications on the PDA can use the...

<Jan> ...interface to obtain keyboard input either from an external keyboard or from other applications that provide simulated keyboard output, such as handwriting interpreters or speech-to-text applications with "keyboard emulation" functionality. Note 2: Operation of the application (or parts of the application) through a keyboard-operated mouse emulator, such as MouseKeys, does not qualify...

<Jan> ...as operation through a keyboard interface because operation of the program is through its pointing device interface, not through its keyboard interface.

Jeanne: WCAG is not being reopened. There is a new device independence working group (Indie-UI), but that is a separate group, not reopening WCAG>

Jan: The kind of emulators we are discussing are primarily navigations - next, next, next, select.
... IndieUI is figuring out high level mappings.

Jeanne: there is cross device mapping as well -- touch = gesture = keyboard = mouse.

Jutta: There were so many keyboard emulators, that it became a general way of saying make it use a keyboard-type interface.
... this is a part of the larger concern.

F2F scheduling

We are out of time, so we will postpone discussion of the F2F scheduling next week.

- DRAFT -

WAI AU

11 Jun 2012

Attendees

Contents

GZ1