See also: IRC log
<AndroUser> Rrsafent, set logs public
<KimPatch> What's the conference code pass code?
<jeanne> http://www.w3.org/WAI/AU/2012/ED-ATAG20-20120113/#principle_a1
<jeanne> http://www.w3.org/WAI/AU/2012/ED-ATAG20-20120113/#principle_a1
1.3.2 c, the word "border" should be plural.
1.3.2 "The user" should not be capitalized as it's after a comma.
<kford> http://test.tsbvi.edu/sc-todo.htm
Re 5.4.2 Handle Unrendered Technologies, not clear how UA should handle an "unrecognized technology" like VBscript embedded in a page. Can't save it to disk...
Jeanne: Might not be accessibility-specific enough.
Jeanne will add to survey proposal to delete it.
ATAG combined all three levels into a single success criterion.
<jeanne> A.1.1.1 Web-Based Accessible (WCAG):
<jeanne> Web-based authoring tool user interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria)
5.4.1 Web-Based Accessible (WCAG): Web-based authoring tool user interfaces meet the WCAG 2.0 success criteria, Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria. (Level A)
5.4.1 Web-Based Accessible (WCAG): Web-based authoring tool user interfaces meet the WCAG 2.0 success criteria: Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria. (Level A)
Jeanne: Combine all three
Guidelines under Principle 5.
... that would be a total of 6 SC, 1 from former 5.1, 2 from
5.2, and 3 from 5.3.
Principle 5 would remain "Comply with applicable specifications and conventions"
The three existing Guidelines would be combined into 5.1 "Comply with applicable specifications and conventions" (same title)?
Jeanne will make the change in the next Editor's draft, and put on the survey for approval.
<jeanne> ACTION: Jeanne to update document to combine 5.2 and 5.4 - use title from 5.1. Also put it into survey. [recorded in http://www.w3.org/2012/01/20-ua-minutes.html#action01]
<trackbot> Created ACTION-705 - Update document to combine 5.2 and 5.4 - use title from 5.1. Also put it into survey. [on Jeanne F Spellman - due 2012-01-27].
<jeanne> edit action-705 Update document to combine 5.2, 5.3 and 5.4 - use title from 5.1.
Re 5.4.1 instead of the title being "Web-Based Accessible", how about simply "WCAG Compliant".
<jeanne> ACTION: Jeanne to update 5.4.1 with text: 5.4.1 WCAG Compliant: Web-based authoring tool user interfaces meet the WCAG 2.0 success criteria: Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria. (Level A) [recorded in http://www.w3.org/2012/01/20-ua-minutes.html#action02]
<trackbot> Created ACTION-706 - Update 5.4.1 with text: 5.4.1 WCAG Compliant: Web-based authoring tool user interfaces meet the WCAG 2.0 success criteria: Level A to meet WCAG 2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA success criteria; Level AAA to meet all WCAG 2.0 success criteria. (Level A) [on Jeanne F Spellman - due 2012-01-27].
The title doesn't match the SC, nothing about "write access" in it.
This is from 2010:
2.1.5 Write Access: If the user can modify the state or value of a piece of content through the user interface (e.g., by checking a box or editing a text area), the same degree of write access is available programmatically. (Level A)
There is no longer any SC with the phrase "write access" in the current draft.
I think we accidentally replaced the body of the Write Access SC with something else.
The title matches the Intent and Examples.
The old SC last appeared in our editor's draft of 2011-06-09.
Back as far as September 2009, the title "Write Access" had both SC bodies, one about exposing DOM-like internal data structures, and one about providing programmatic write access.
Do we want to keep both? If so, we should restore the one about write access, and give the current SC a new number and name.
Kelly: Delete the existing one about exposing internal data structures. Restore the one about programmatic write access.
Question raised as to whether UA support either one.
Resolved: Jeanne will restore the correct (old) text of the "4.1.5 Write Access" SC from the 20100609 draft, and delete the SC wording about exposing DOM-like data structures.
And put both into the survey.
That is, the correct SC body for 4.1.5 Write Access is "If the user can modify the state or value of a piece of content through the user interface (e.g., by checking a box or editing a text area), the same degree of write access is available programmatically. (Level A)".
<kford> This text needs to go on a survey, requesting we want to delete.
<kford> If the user agent keeps an internal representation of the user content in terms of element structure, relationships between elements, element meaning, or some combination thereof, it must expose this internal representation via an appropriate means (normally by using the platform accessibility architecture or a programmatically available DOM). (Level A)
In the 20111003 draft, 2.7.5 read 2.7.5 Restore related preferences to default:
The user can restore groups of related preference settings to default values (e.g. reset keyboard shortcuts, reset colors and sizes of rendered content). (Level AA)
There was no 2.7.5 in the draft of the next day (20111004).
Agreement to leave it deleted.
Kelly: the summary for this whole section is wrong.
The summary for 2.5 discuses 2.7.
Kelly: the summary for 2.7 still describes 2.7.5, which has been deleted.
"Users can manage multiple sets of preference settings and restore groups of settings to defaults (2.7.4, 2.7.5)" will change to:
"Users can manage multiple sets of preference settings(2.7.4)"
"Users can configure and restore accessibility preference settings (2.7.1, 2.7.3)" would change to:
"Users can restore preference settings to their default (2.7.3)"?
<scribe> New text:
Summary: Users can restore
preference settings to default (2.7.3), and accessibility
settings persist between sessions (2.7.2). Users can manage
multiple sets of preference settings (2.7.4), and adjust
preference setting outside the user interface so the current
user interface does not prevent access (2.7.6). It's also
recommended that groups of settings can be transported to
compatible...
... systems, and a wizard be available to help users configure
their preferences (2.7.7, 2.7.8).
Jeanne is making that change.
Greg: Can't find a summary of 2.5 in older drafts.
Wayne: Shouldn't write one now as the entire 2.5 section is up for major reworking.
2.3.5 is noted as overlapping with 2.1.4.
2.3.5 Allow Override of Accesskeys (former 2.1.11): The user can override any recognized author supplied content keybinding (i.e. access key). The user must have an option to save the override of user interface keyboard shortcuts so that the rebinding persists beyond the current session. (Level AA)
2.1.4 Specify preferred keystrokes (former 2.1.2): The user can override any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user interface controls, except for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). (Level A)
Kelly: the major difference is that 2.3.5 adds persistence and Level AA.
Greg: Also 2.3.5 is content, but 2.1.4 is content and UA UI.
Could combine them, addressing both content and UA UI, requiring persistence, but being Level AA.
I don't think we can justify making the ability to override keyboard shortcuts Level A.
Does the combined SC go into Guideline 2.1 - Ensure full keyboard access, or Guideline 2.3 - Provide direct navigation and activation.
2.3 seems more appropriate.
<scribe> New version something like this?
2.3.5 Customize Keyboard Commands: The user can override any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user interface controls, except for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). The user must be able to save these settings beyond the current session. (Level AA)
Use this version, delete 2.1.4.
Kelly: Need to change various
Summaries, Intents and Examples.
... Don't feel we need to put in the survey, as no concept is
being deleted, only reduced in priority.
<kford> ACTION: JAllan to combine intents from 2.1.4 and 2.3.5 and examples. [recorded in http://www.w3.org/2012/01/20-ua-minutes.html#action03]
<trackbot> Created ACTION-707 - Combine intents from 2.1.4 and 2.3.5 and examples. [on Jim Allan - due 2012-01-27].
The text is missing some words, represented by @@ in the notes.
We may need to exclude platform conventions, e.g. we don't want to require that it allow the user to turn off wrapping in menus if the OS doesn't support that platform-wide.
Oh, this is only for content!
It could be "When user interaction with web content causes focus wrapping at the beginning or end of a document or section..."?
Jim and Kelly: Should only be at end of document, not within a radio button group, for example.
Kelly: "at the document level"?
Jeanne: have to address apps.
2.2.4 Options for Wrapping in Navigation (new): When user interaction with web content causes focus wrapping at the beginning or end of a document, the user can prevent wrapping or the user can receive feedback when wrapping. (Level AA)
Alternative structure:
2.2.4 Options for Wrapping in Navigation (new) : The user can prevent sequential navigation from wrapping the focus at the beginning or end of a document, and can receive notification when such wrapping occurs. (Level AA)
2.2.4 Options for Wrapping in Navigation (new) : The user can prevent sequential navigation from wrapping the focus at the beginning or end of a document, and can request notification when such wrapping occurs. (Level AA)
Approved.
Comment read "combine 213 here, remove 213"
2.2.2 Sequential Navigation Between Viewports [NEW]: The user can move the keyboard focus backwards and forwards between viewports, without having to sequentially navigate all the elements in a viewport. (Level A)
2.1.3 Viewport Navigation (former 1.9.2 & 1.9.4): The user can move the active keyboard focus to any viewport. (Level A)
2.2.2 looks better.
However, it does not require that all viewports be able to take the focus, as 2.1.3 does.
Do we want to require that all viewports can take the keyboard focus?
2.2.2 Sequential Navigation Between Viewports [NEW]: The user can move the keyboard focus backwards and forwards between viewports, without having to sequentially navigate all the elements in a viewport. (Level A)
2.1.3 Viewport Navigation (former 1.9.2 & 1.9.4): The user can move the active keyboard focus to any viewport. (Level A)
2.2.2 looks better, but iit does not require that all viewports be able to take the focus, as 2.1.3 does.
Jim: We can't require all viewports take keyboard focus, as paper is a viewport.
I guess it's not necessarily required to say that the user can move the keyboard focus to every window and frame, given that we require they be able to do anything with the keyboard that they can do with the mouse. Thus, if they can select something in a popup window (for eaxmple) using mouse, they would have to have *some way* of doing it with the keyboard, even if it doesn't involve...
scribe: moving the focus to the window.
<AllanJ> I like wording in 222. and not mention 'any'.
But it would be possible that a window has functionality the user can perform through other means, but they'd have no way of exploring it by moving the keyboard focus through it.
Agreement to delete 2.1.3, keep 2.2.2 as it is. (I'm nervous about it, but OK.)
<AllanJ> ACTION: jallan to merge intents of 213 and 222 and fix the summaries of 2.1 and 2.3 [recorded in http://www.w3.org/2012/01/20-ua-minutes.html#action04]
<trackbot> Created ACTION-708 - Merge intents of 213 and 222 and fix the summaries of 2.1 and 2.3 [on Jim Allan - due 2012-01-27].
Jim: Note says "email thread"
Jim will look into that offline.
<AllanJ> ACTION: jallan find the email thread about 1112 and send to list [recorded in http://www.w3.org/2012/01/20-ua-minutes.html#action05]
<trackbot> Created ACTION-709 - Find the email thread about 1112 and send to list [on Jim Allan - due 2012-01-27].
<Wayne> www.csulb.edu/~wed/ua/1.7
That's the last of the SC noted in http://test.tsbvi.edu/sc-todo.htm that don't already have action items associated with them.
Discussion of the term "style profiles" used in UAAG today vs. "style sheets" which is an official W3 term.
<Wayne> Guideline 1.7 - Enable Configuration of Style Profiles [Implementing 1.7]
<Wayne> Summary: The user agent shall support user style profiles 1.7.1, and the user can choose use or not use author-supplied style profiles (1.7.1). Moreover, user-supplied style profiles and author supplied style profiles can be turned on or off at any time within a session with a user agent. .
<Wayne> New definitions
<Wayne> Style Profile
<Wayne> An identified collection of style rules is a style profile.
<Wayne> Style Rule
<Wayne> A style rule is an assignment of presentation properties to a group of content that can be assigned presentation properties.
<Wayne> These groupings of content that occur in style rules be defined in three ways:
<Wayne> Language: The content definition language identifies groupings of content as part of a document's semantic structure to support generic separation of content from presentation, e.g. headings, lists, paragraphs etc.
<Wayne> Author: The author defines groupings of content to assign presentation properties that enhance the meaning of the document, e.g. content classes, spans and divisions etc.
<Wayne> User: The user defines groupings of content to assign presentation properties to meet adaptation needs.
<Wayne> 1.7.1 User Supplied Style Profiles
<Wayne> User agents that support a mechanism for authors to supply style profiles shall also provide an equally effective mechanism for users to supply profiles.(Level A)
<Wayne> 1.7.2 Author Supplied Style Profiles
Wayne: Worried that some user agents don't implement style sheets in the W3 format.
<Wayne> The user can turn author style sheets on or off the for any page.: (Level A)
<Wayne> 1.7.3 User Supplied Style Profiles:
<Wayne> The user has the option to change from author to user to no style profiles as many times as necessary within a session with a user agene: (Level AA) (Supported by IE and Safari)
Wayne: PDF, Flash and Silverlight
don't support stylesheets but claim to separate content from
presentation, so must have something equivalent to stylesheets.
Most word processors have style templates (e.g. Microsoft Word
.dot files). There are many things on the web, but if the only
one we require style sheets (meaning HTML and related
technologies) and it ignores other technologies,
people...
... will be excluded from reading documents in those
formats.
... if a document format and reader don't allow the user to
substitute their own set of formatting styles, that's fine but
they should not claim to be accessible.
<Wayne> http://www.csulb.edu/~wed/ua/1.7.html
Wayne: No way to do this with PDF, for example.
<Wayne> Opera gives the choice of user style, author style and no style (html 4.01) default.
<Wayne> Safari give user or author style.
<Wayne> IE gives user or author
<Wayne> Firefox gives author / none / restricted user (one time only)
<Wayne> When can you change: One time per sesssion or dynamically
<Wayne> one time persession: chrome and firefox
<Wayne> dynamic IE and Safari are dynamic
Specifically, Firefox allows you to change between author style sheet and no style sheet at any time, but user style sheets are only at session start.
Wayne: Proposed rewrite would
remove the requirement that users be able to turn on and off
author style sheets individually, because he's never needed
it.
... Also lose ability to save author style sheets so the user
can modify them, worried about copyright problems.
Greg: So if you want to write a user style sheet you'd have to do it from scratch?
Wayne: Creating user style sheets
is hard, only experts will be doing it.
... if you really work in large print, a person with low vision
usually starts with at least 20 pt font, and most pages break
if you enlarge them that far.
... Thus to use large print you need to totally take over
presentation from the author.
Jeanne: "element-level control over the text presentation", instead of "style sheets" or "style profiles"?
Wayne: Looking for style sheets
is a fundamental function of browsers, so telling it to look
elsewhere for style sheets is not a major change.
... Allowing the user to configure at the element level would
be wonderful, but still need to save it somehow.
Jeanne: Thinking about what you can say about non-W3 technologies, which don't have concept of going out for style sheets. Would need major change, allowing user to inspect document and apply style changes to it.
<Wayne> html -- element class, pdf-- tag class
So part of my concern is that changing 1.7 from only applying to UA that support style sheets or equivalent to applying to ALL user agents might make it impossible for large classes of user agents to comply, e.g. media players.
We all agree that user control over style sheets and equivalent is an incredibly important piece of accessibility, but we have to write these SC very, very carefully to avoid unanticipated consequences.
<AllanJ> Meeting UAWG Jan. 20 2012
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/keygboard/keyboard/ No ScribeNick specified. Guessing ScribeNick: Greg Inferring Scribes: Greg Default Present: Greg_Lowney, Jim_Allan, Jeanne, Kim_Patch, kford, Wayne, [Microsoft] Present: Greg_Lowney Jim_Allan Jeanne Kim_Patch kford Wayne [Microsoft] WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 20 Jan 2012 Guessing minutes URL: http://www.w3.org/2012/01/20-ua-minutes.html People with action items: jallan jeanne WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]