W3C

Authoring Tool Accessibility Guidelines Working Group Teleconference

15 Jun 2009

See also: IRC log

Attendees

Present
AnnM, Jan_Richards, Reed_Shaffner, Sueann_Nichols, Jutta_Treviranus, Jeanne_Spellman, ARonksley, Tim_Boland, Greg_Pisocky, Ann_McMeekin, Andrew_Ronksley
Regrets
Chair
jutta, jan
Scribe
Greg, reed, Sueann

Contents


Review of public comments

<jeanne> ACTION: JS to update Glossary to move the definition of Authoring Tool User Interface before the def of the Web based and non-Web based definitions [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action01]

<trackbot> Created ACTION-156 - Update Glossary to move the definition of Authoring Tool User Interface before the def of the Web based and non-Web based definitions [on Jeanne Spellman - due 2009-06-22].

<Greg> Conducting review of public working draft http://www.w3.org/WAI/AU/2009/ED-ATAG20-20090612

Guildline A.1.1

<Greg> Resolution: Remove applicability note A.1.1 based upon public feedback.

<Greg> Topic Guidelin A.1.2

<jtrevir> Rationale: Authoring Tools that are Web applications are Web content that should conform to WCAG 2.0.

<jtrevir> This will support the accessibility of the authoring tool user interface and will facilitate communication with assistive technologies via user agents.

<Greg> A.1.2.1

A.1.2.1

<Greg> Proposal by JR for A.1.2.1 Non-Web based authoing tool user interfaces follow (and cite in the conformance claim) accessibility standards and/or platform conventions that support accessibility. (Level A)

<Jan> A.1.2.1 Non-Web-Based Accessible (Level A): Non-Web-based authoring tool user interfaces follow (and cite in the conformance claim) accessibility standards and/or platform conventions that support accessibility. (Level A)

<Greg> Resolution Remove Applicability note for A.1.2.1

<Greg> A.1.1 Rationale

<jeanne> ACTION: JT to reword the rationale for A.1.2 for clarity and grammar [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action02]

<trackbot> Created ACTION-157 - Reword the rationale for A.1.2 for clarity and grammar [on Jutta Treviranus - due 2009-06-22].

<Sueann> Guideline A.2.1 [For the authoring tool user interface] Provide access to alternative content in the Web content.

<Sueann> This is about non-text content - why not state that? Provide access to text alternatives for any non-text content in rendered views of Web content.

A.2.1

Guideline A.2.1

<jeanne> JT: Make alternative content available to the author.

<jeanne> scribe: Greg

<Jan> A.2.1 Make alternative content available to the author.

Guideline A.2.1 rationale

<Jan> Some authors require access to alternative content in order to interact with the Web content that they are authoring.

<Sueann> A.2.1.1. The definition of alternative content is inadequate to address this guideline. you may in fact have a flexible system which may require full equivalent replacements for the content defined by user preferences such as a table or accessible datagrid equivalent for a complex visualization. The system may in fact generate alterative content that would be more accessible to an individual user. Although WCAG does not address this ATAG certainly could while st

<Sueann> Although WCAG does not address this ATAG certainly could while still supporting WCAG. How the user specifies this equivalent will be based on their need. ... Think Access for All or ISO DRD/PNP

<jeanne> ACTION: JS to change "authors" to "author(s)" [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action03]

<trackbot> Created ACTION-158 - Change "authors" to "author(s)" [on Jeanne Spellman - due 2009-06-22].

<ReedShaff> stylistic note to change authors to author(s) throughout the standard

<Jan> A.2.1.1 Recognized Alternative Content: When recognized alternative content is available@@define??@@ for Web content being edited, the authoring tool makes the alternative content accessible to the author(s).

<jeanne> ACTION: JR to write a proposed defintion of "available" [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action04]

<trackbot> Created ACTION-159 - Write a proposed defintion of "available" [on Jan Richards - due 2009-06-22].

<jeanne> send comments to the public list at: public-atag2-comments@w3.org

Guideline A.2.2 Rationale

<Sueann> 2.2 wording needs to harmonize with WCAG; i.e. use "programmatically determinable" instead of "available via the platform

<jeanne> We are taking a 15 minute break. Reconvening at xx:30

<AnnM> will be back in 15 minutes.

<jeanne> ACTION: JR to propose a definition of programmatically determined. [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action05]

<trackbot> Created ACTION-160 - Propose a definition of programmatically determined. [on Jan Richards - due 2009-06-22].

<AnnM> yup

<Jan> A.2.2.1 Purpose of Added Presentation: If an editing view modifies the presentation of Web content to provide authors with additional information, then that additional information can be *programmatically determined*. (Level A)

<Jan> A.2.2.2 Access to Text Presentation (Minimum): If any of the following properties are present in the Web content and are rendered in an editing view (e.g., WYSIWYG view) they can be *programmatically determined*. (Level A): @@wordsmith?@@

<Jan> (a) text font,

<Jan> (b) text style (e.g., italic, bold),

<Jan> (c) text color, and

<Jan> (d) text size.

<jeanne> zakim Adobe also has Greg_Pisocky

Guideline A.2.3

<Jan> Rationale: Some authors need to set display settings for themselves that differ from the presentation that they define for the published Web content.

<jeanne> Here is the link to the updated comments document: http://www.w3.org/WAI/AU/2009/ED-ATAG20-20090612/atag20_pubWD_21may2009_comment_responses.html

<Sueann> The definition of visual and audio display settings states nothing about where they are set. These should reflect "platform" settings and user-defined application settings (Firefox, Safari 4, IE zoom features).

<jeanne> ACTION: JR to write a definition for Display Preferences. [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action06]

<trackbot> Created ACTION-161 - Write a definition for Display Preferences. [on Jan Richards - due 2009-06-22].

<Jan> A.2.3.1 Independence of Display: Editing views that render content (e.g., WYSIWYG) allow the authors' own display preferences @@JR DEFINE@@ to take precedence in the editing view without affecting the Web content being edited (i.e., no effect on markup, style sheets, etc.). (Level A)

<jeanne> 4.1.8 Important Command Functions: Important command functions (e.g. related to navigation, display, content, information management, etc.) are available in a single keystroke. (Level AA)

<jeanne> ... from UAAG

Checkpoint A.3.1.1 Important Commands

<Jan> A.3.1.1 Keyboard: All functionality of the authoring tool is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)

<Jan> Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

<Jan> Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

<Jan> A.3.1.3 Keyboard Shortcuts: The authoring tool provides keyboard shortcuts. (Level AA)

<Jan> A.3.1.4 Customize Keyboard Access: The authoring tool allows authors to customize keyboard access. (Level AAA)

Lunch 1 hour will resume at 2:05 eastern

resumed at 2:05

Guideline A.3.2

Jeanne looking for an explanation of the "moving targets" in the rationale

<ReedShaff> scribe: reed

<jeanne> scribenick:ReedShaff

<RS and Sueann> commenting on contradictions in time limits

discussing WCAG wording as is and what to take over

<JR> Just grab text from WCAG?

Agreement from group

A.3.2.2 to be replaced with WCAG 2.2.1

Change A3.2

Changed to Provide authors with enough time

JT: Sounds a little off still

JR: It could also apply to use of help system

s

JR: Can someone take on A3.2.2?

<scribe> ACTION: JS to provide new text for A3.2.2 and moving targets [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action07]

<trackbot> Created ACTION-162 - Provide new text for A3.2.2 and moving targets [on Jeanne Spellman - due 2009-06-22].

<jeanne> ACTION: JS to write proporsal for A.3.2 rationale and Guildline text [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action08]

<trackbot> Created ACTION-163 - Write proporsal for A.3.2 rationale and Guildline text [on Jeanne Spellman - due 2009-06-22].

<jeanne> close action 163

Sueann: not sure I get the moving targets piece, what does moving targets have to do with time limits?

<Sueann> I'm not sure how

<Sueann> A.3.2.3 Moving Targets: If a user interface component that accepts mouse input is capable of movement (e.g., animated vector graphic), provide authors with the option to stop the movement. (Level A)

<Sueann> relates to A.3.2 - since moving targets doesn't seem to have anything to do with time limits. Maybe A.3.2 should be more broadly worded. I think the original wording (from the techniques document Enable time-independent interaction. makes more sense.

TB: why capable of movement and not is moving?

JR: Yeah, like that

JS: can we take out accepts mouse input?

JR: it doesn't always have to be editable

JT: if a user interface component is moving

JR: yeah, alright
... should I get rid of eg?
... If JS can work something in about why stopping a moving target provides enough time, would that make it better?

Sueann: stretch

JS: I now have 4

comments on this section

JS seems to have proposal that will satisfy

<jeanne> People who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits or requiring a short reaction speed, such as clicking on a moving target.

JS: probably should be short reaction time
... fast reaction speed?

<Jan> Rationale: Some authors who have difficulty typing, operating the mouse, or processing information can be prevented from using systems with short time limits or requiring a fast reaction speed, such as clicking on a moving target.

JR: Can we move on to A3.3

on A 3.3

JR: checking to see what WCAG uses

JS: I will take this as an editorial change

<jeanne> ACTION: JS to do a global update of "photosensitive epilepsy" to "photosensitive seizure disorder" [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action09]

<trackbot> Created ACTION-164 - Do a global update of "photosensitive epilepsy" to "photosensitive seizure disorder" [on Jeanne Spellman - due 2009-06-22].

JR: rationale, we do this because it's difficult for an authoring tool to prevent the multitude of content and predicting what will flash, we try and solve that at the global level
... even if we had levels, how would that work on things like videos

JS: maye we could call it option for static view

Moving on

<Sueann> A.3.4.1 The definition of structured element sets is too limiting. It should not just in include organized elements. Headings are considered structural yet in and by themselves they do not imply a collection of oranized elements. ARIA landmarks should be included as well. The definition of structured element should be that of a significant semantic areas of the page which in turn support the structure of the web page. You might even refer to the WAI-ARIA taxono

<jeanne> http://www.w3.org/TR/2009/WD-wai-aria-20090224/#state_prop_taxonomy

JR: send as an action item to someone, no issue with things being a structured element set, just definition
... other than that?
... oh there was asuggest about moving navigate by heading to level A

<scribe> Closed on A3.4 for now

Moved to A3.5

<Sueann> ACTION: SN A3.4.1 come up with a recommendation on how to address adding WAI-ARIA like taxonomy [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action10]

<trackbot> Created ACTION-165 - A3.4.1 come up with a recommendation on how to address adding WAI-ARIA like taxonomy [on Sueann Nichols - due 2009-06-22].

atrribute and formatting added in response to comment

comment: seems werid thisn refers to UI when this really talking about searching for content

JR: that's why i say of the content

Sueann: in 3.5 dont understand use of web content here, shouldn't this apply to editing views, this applies that the web content is output of the tool, should this be covered in B

JR: maybe we make a slight tweek to clarify it's within the web content being authored

Leaving A3.5

Moving to A3.6

<Jan> Rationale: Authors who have difficulty typing or operating the mouse benefit from the ability to navigate to arbitrary points within the Web content being authored.

Any comments on A3.6?

<jeanne> scribe:Sueann

move to a.3.7

A.3.7

If authoring tools are required to be WCAG compliant, why are previews a special case? It would seem that they should be subject to the same set of rules.

- Why is there a reference to UAAG 1.0? Has the ATAG working group looked at UAAG 1.0 and identified guidelines that if employed would be counter WCAG 2.0 and ATAG 2.0 objectives or today's best practices? For example, guideline 4.1 is outdated in UAAG. All user agents today provide full magnification rather than just text which is much more accurate. Should you still be require font size increases.

This is a preview and reflects the current state in the authoring process

4.1 Applicability note - It is acceptable for certain committing actions (e.g., "save", "publish") to to make all previous authoring actions irreversible. (to to) typo

Jan looking to remove applicability note in 4.2

A.4.2.1 and A.4.2.2 - needs editorial work. When I first read it, I didn't get it as all product features are required to meet part A. But then I realized it's trying to say that if your product has implemented functions in support of the requirements in Part A, you have to document those functions

15 min break...

Continuing

Jan recommending removing the AAA requirement for tutorials A.4.2.2, additional concern where would we get an implementation.

<Jan> Rationale: Some authors may not be able to understand or operate the authoring tool user interface without proper documentation.

<scribe> Agenda: review of levels with a focus on AAA to ensure the requirements can be implemented

on to part B

change in 3. Existing Technologies

Jean would like 1. Author Availability editing changes

and 4. Authoring Systems

<Jan> Existing Technologies: The success criteria in Part B only apply to support for production of Web content using the Web content technologies that are included in the conformance profile.

Jan: remove b.1.1 add clarification in the AGAG 2.0 conformance profile

IBM comment:Guideline B.1.1

This seems to restrictive. An authoring tool may support include support for all kinds of markup. If one markup, like SVG, which does not fully support assistive technologies is chosen the whole rest of the tool fails? Recommend that the author be given the choice of choosing only accessible technologies. In that mode it should be considered to satisfy this guideline - unless there are none.

This section should also allow for the selection of equivalent alternatives that are accessible. Take a Mashup authoring tool. A chart may be inaccessible but a table equivalent may be acceptable. You might even take into account user preferences.

The section refers to accessible Web content but the definition of accessible web content refers to a particular level of WCAG. Why should an ATAG 2.0 compliant tool support WCAG 1.0 when in fact the guidelines for being ATAG 2.0 compliant require that the authoring tool meet WCAG 2.0 requirements? I disagree that this should include all versions of WCAG.

Need to add a note to handle the case when a technology that can not be made accessible is used an alternative solution can be used to provide an accessible alternative.

getting rid of b.1.1 and fixing the conformance claim

add a bullet item under conformance claim 5 to include web technologies used to provide an alternative conforming version

Jean raised the question should this be a moved out of the claim, and be a guideline in b.2.1

<scribe> new guideline to support the idea that alternative content, alternative technology be used, and made available by the tool

for the creation of an alterntive to the content that is not accessible.

not sure where this will go -Jean suggested b.2.1

<scribe> new guideline "if a web content technology included in the conformance profile cannot be used to create accessible Web content, then a "conforming alternative version" in another web content technology must also be make available prior to publication.

this still needs work

issues: there are lots of different "tools" that make up parts of an entire web content solution.

Jean: original comment was to address mashups, not part of the conformance claim.

first issue is the task that is being performed, in the case of an animation there the author would not use html. the image or "paint" program won't be accessible.

Jan: can we change the definition of web content technologies to include a conforming alternative for technologies that are not accessible.

<jeanne> Sueann: We need a definition of "Accessible Web Content Technologies" that is the sum of the parts of the Web Content TEchnologis.

Jean suggested we table this and several of us take this and proposals

next step: come up with an agenda for Tue.

<scribe> agenda: brainstorm people and organizations to invite to review

review levels - AAA

complete the review of feedback in Section B

triage comments - what needs to be worked f2f vs. assigned for action

techniques?

would be very helpful to have a tool that has mapped to the atag success criteria to see what the conformance is

Summary of Action Items

[NEW] ACTION: JR to propose a definition of programmatically determined. [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action05]
[NEW] ACTION: JR to write a definition for Display Preferences. [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action06]
[NEW] ACTION: JR to write a proposed defintion of "available" [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action04]
[NEW] ACTION: JS to change "authors" to "author(s)" [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action03]
[NEW] ACTION: JS to do a global update of "photosensitive epilepsy" to "photosensitive seizure disorder" [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action09]
[NEW] ACTION: JS to provide new text for A3.2.2 and moving targets [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action07]
[NEW] ACTION: JS to update Glossary to move the definition of Authoring Tool User Interface before the def of the Web based and non-Web based definitions [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action01]
[NEW] ACTION: JS to write proporsal for A.3.2 rationale and Guildline text [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action08]
[NEW] ACTION: JT to reword the rationale for A.1.2 for clarity and grammar [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action02]
[NEW] ACTION: SN A3.4.1 come up with a recommendation on how to address adding WAI-ARIA like taxonomy [recorded in http://www.w3.org/2009/06/15-au-minutes.html#action10]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/06/15 21:15:29 $