RE: AUWG Teleconference on 9 January 2012 3:00pm-4:00pm ET

Minutes:
http://www.w3.org/2012/01/09-au-minutes.html

Full text:
WAI AU
09 Jan 2012

Agenda

See also: IRC log
Attendees

Present
Regrets
Chair
    Jan Richards
Scribe
    Jan, andrewronksley

Contents

    Topics
        1. Part A Conformance Applicability Note: Platform limitations
        2. A.2.2.2 Access to Rendered Text Properties:
        3. A.3.1.1 Keyboard Access (Minimum)
        4. A.3.1.5 Customize Keyboard Access
        5. A.3.1.6 Present Keyboard Commands
        6. A.4.2.1 Document Accessibility Features
        7. B.3.1.1 Checking Assistance (WCAG)
        8. (Tentative) Conformance Requirements
        9. (Tentative) Table of Accessibility Information types in the Implementing doc
        10. Note on Term " accessibility information (WCAG)"
        12. Term "keyboard interface"
    Summary of Action Items

<Jan> Scribe:Jan
1. Part A Conformance Applicability Note: Platform limitations

http://lists.w3.org/Archives/Public/w3c-wai-au/2012JanMar/0001.html
2. A.2.2.2 Access to Rendered Text Properties:

<scribe> Scribe: andrewronksley

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#sc_a222

JR: The idea is that the text editor serves two purposes. It serves as a text editor but also it's a part of a workflow.

<Jan> JR: ANy objections to the SC wording?

<Jan> Resolution: All agree with "A.2.2.2 Access to Rendered Text 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."

JR: The level is currently A. Wondering if this should be AA?
... It's not preventing authors from editing something. It's making something more effective.

<Jan> Resolution: Change A.2.2.2 Access to Rendered Text Properties to AA
3. A.3.1.1 Keyboard Access (Minimum)

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#sc_a311

JR: Some questions raised about devices that don't have a keyboard. We're not trying to imply that the device has to have a physical keyboard. We've added a note to clarify this.

JS: I would use the phrase "hardware" keyboard rather than "conventional" keyboard.

Not all software keyboards have tab and arrow keys

There's often alternative (third party) keyboards available that do have these keys though.

<Jan> 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> Resolution: All accept: 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> Note 3: This success criterion does not forbid and should not discourage @@other input methods (e.g., mouse, touch) in addition to keyboard operation.

<Jan> Resolution: All accept: "Note 3: This success criterion does not forbid and should not discourage other input methods (e.g., mouse, touch) in addition to keyboard operation."

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#sc_a311-i

<Jan> Note 1 clarifies that the success criterion does not require a hardware keyboard to be present. Many mobile platforms lack hardware keyboards, but nonetheless provide "keyboard interfaces".

<Jan> Resolution: All accept "Note 1 clarifies that the success criterion does not require a hardware keyboard to be present. Many mobile platforms lack hardware keyboards, but nonetheless provide "keyboard interfaces"."
4. A.3.1.5 Customize Keyboard Access

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#sc_a315-i

<Jan> Resolution: All accept "@@on platforms that support keyboard commands"
5. A.3.1.6 Present Keyboard Commands

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#sc_a316-i

<Jan> Resolution: All accept "@@on platforms that support keyboard commands " for A.3.1.6
6. A.4.2.1 Document Accessibility Features

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#sc_a421

What if the feature requires no action on the user's part?

Things like programatically determined. Users don't get involved with that stuff.

<Jan> A.4.2.1 Document Accessibility Features: All features of the authoring tool that are used direclty by the author and that are used to meet Part A of ATAG 2.0 (e.g., keyboard shortcuts, text search) are documented.

<Jan> Jeanne: A.4.2.1 Document Accessibility Features: All features of the authoring tool that require author interaction and that are used to meet Part A of ATAG 2.0 (e.g., keyboard shortcuts, text search) are documented.

JR: There's things that are so trivial that they probably don't need documenting
... e.g. a search box

GS: Section 508 does have a requirement for documentation of accessibility features
... How do you count features though

Alex: once you start counting you realise it's practically impossible

GS: Section 508 doesn't comment on the quality of the documentation, just that it's available.

JR: I think what we're getting at is some accessibility features will be hard to use without documentation, e.g. keyboard shortcuts.

GS: The other issue that comes into play is platform or OS conventions.
... There's an assumption that people will know a certain amount.
... e.g. on Windows CTRL+O for open etc.

Alex: Normally the platform should provide documentation relating to things such as this.

GS: Getting back to the notion of trivial, we assume users know the conventions for their platform. That being said, users still ask us to document these kinds of things.

JR: Maybe what trivial means in this case is things that are common to a platform.

<Jan> ACTION: JR to To propose something for A.4.2.1 that includes user interactive features and a note on platform conventions being documented elesewhere [recorded in http://www.w3.org/2012/01/09-au-minutes.html#action01]

<trackbot> Created ACTION-370 - Propose something for A.4.2.1 that includes user interactive features and a note on platform conventions being documented elesewhere [on Jan Richards - due 2012-01-16].
7. B.3.1.1 Checking Assistance (WCAG)

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#sc_b311

<Jan> Resoltuion: All accept "@@in such a way" in B.3.1.1

<Jan> Resolution: All accept "@@in such a way" in B.3.1.1
8. (Tentative) Conformance Requirements

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#conf-req

<Jan> Everyone will take an action to look at the (tentative) confromance requirements http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#conf-req

<Jan> 9. (Tentative) Table of Accessibility Information types in the Implementing doc
9. (Tentative) Table of Accessibility Information types in the Implementing doc

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#prompting-types

<Jan> Resolution: To remove the tentative marking on the Table of Accessibility Information types (i.e. to keep the table)
10. Note on Term " accessibility information (WCAG)"

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#def-Accessibility-Information

<Jan> remove ")" at end of accessibility info

<Jan> Resolution: Alll accept "Note: For the purposes of ATAG 2.0, only programmatically determinable information qualifies. For additional examples, see Appendix A of the Implementing ATAG 2.0 document."
12. Term "keyboard interface"

<Jan> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/#def-Keyboard-Interface

<Jan> A programmatic interface used by software to obtain keystroke input. A keyboard interface can allow keystroke input even if particular devices do not contain a hardware keyboard (e.g., a touchscreen-controlled device can have a keyboard interface built into its operating system to support onscreen keyboards as well as external keyboards that may be connected).

<Jan> Note: Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces.

<Jan> 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 conventional keyboard.

<Jan> Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. A keyboard interface can allow keystroke input even if particular devices do not contain a hardware keyboard (e.g., a touchscreen-controlled device can have a keyboard interface built into its operating system to support onscreen keyboards as well as external...

<Jan> ...keyboards that may be connected).Note: Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces.

<Jan> Resolution: All accept "Keyboard interfaces are programmatic services provided by many platforms that allow operation in a device independent manner. A keyboard interface can allow keystroke input even if particular devices do not contain a hardware keyboard (e.g., a touchscreen-controlled device can have a keyboard interface built into its operating system to support onscreen keyboards as...

<Jan> ...well as external keyboards that may be connected).Note: Keyboard-operated mouse emulators, such as MouseKeys, do not qualify as operation through a keyboard interface because these emulators use pointing device interfaces, not keyboard interfaces.

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


> -----Original Message-----
> From: Richards, Jan
> Sent: January 6, 2012 11:02 PM
> To: w3c-wai-au@w3.org
> Subject: AUWG Teleconference on 9 January 2012 3:00pm-4:00pm ET
> 
> There will be an AUWG teleconference on Monday 9 January 2012 at 3:00 pm
> - 4:00 pm ET:
> 
> Call: (617) 761-6200 ext. 2894#
> IRC: server: irc.w3.org, port: 6665, channel: #au
> 
> If people think they will arrive more than 15 minutes late, please send me an
> email beforehand.
> 
> The dial-in numbers for Zakim are now ONLY:
> ===========================================
> +1.617.761.6200 (Boston)
> 
> 
> Editor Drafts:
> ==============
> ATAG 2.0
> http://www.w3.org/WAI/AU/2011/ED-ATAG20-20111222/
> Implementing ATAG 2.0
> http://www.w3.org/WAI/AU/2011/ED-IMPLEMENTING-ATAG20-20111222/
> 
> IMPORTANT NOTE: This item was agreed last meeting but is erroneously still
> marked @@:
> -  Removing note in B.2.4.1 Accessible Template Options (WCAG) -
> http://www.w3.org/2011/12/19-au-minutes.html#item07
> 
> Agenda:
> ========
> 
> We are getting there!
> 
> Open Items (@@'s) in the draft:
> - Conformance Applicability Notes: 1
> - Major SC rewordings:  1
> - Minor SC wordings: 3
> - Intent-Examples-Resources: 3
> - Glossary terms:  2
> - Tentative "Conformance Requirements" Section
> - Tentative "Accessibility Information" Table
> 
> 1. Part A Conformance Applicability Note: Platform limitations
> 
> 2. A.2.2.2 Access to Rendered Text Properties:
> - SC: 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
> - Level?
> 
> 3. A.3.1.1 Keyboard Access (Minimum)
> - Note 1
> - Note 3
> - Intent
> 
> 4. A.3.1.5 Customize Keyboard Access
> - Intent
> 
> 5. A.3.1.6 Present Keyboard Commands
> - Intent
> 
> 6. A.4.2.1 Document Accessibility Features:
> - SC
> 
> 7. B.3.1.1 Checking Assistance (WCAG)
> - SC
> 
> 8. (Tentative) Conformance Requirements
> 
> 9. (Tentative) Table of Accessibility Information types in the Implementing
> doc
> 
> 10. Note on Term " accessibility information (WCAG)"
> 
> 11. Term "content generation (content authoring, content editing)"
> 
> 12. Term "keyboard interface"
> 
> Future meetings (needs updating):
> ================
> January 16, 2012
> January 23, 2012
> January 30, 2012
> 
> Cheers,
> Jan
> 
> 
> (MR) JAN RICHARDS
> PROJECT MANAGER
> INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)
> 
> T 416 977 6000 x3957
> F 416 977 9844
> E jrichards@ocadu.ca
> 
> Twitter @OCAD
> Facebook www.facebook.com/OCADUniversity
> 
> OCAD UNIVERSITY
> 205 Richmond Street West, 2nd Floor, Toronto, Canada  M5V 1V3
> www.ocadu.ca idrc.ocadu.ca

Received on Monday, 9 January 2012 21:10:13 UTC