minutes jan 20, 2012

 from http://www.w3.org/2012/01/20-ua-minutes.html - DRAFT -
SV_MEETING_TITLE 20 Jan 2012

See also: IRC log <http://www.w3.org/2012/01/20-ua-irc>
Attendees
PresentGreg_Lowney, Jim_Allan, Jeanne, Kim_Patch, kford, Wayne, [Microsoft]
RegretsChairKellyFord, JimAllanScribeGreg
Contents

   - Topics <http://www.w3.org/2012/01/20-ua-minutes.html#agenda>
      1. 5.4.2 Handle Unrendered
Technologies<http://www.w3.org/2012/01/20-ua-minutes.html#item01>
      2. 5.2.3 Web-Based Accessible (Level
AAA)<http://www.w3.org/2012/01/20-ua-minutes.html#item02>
      3. 4.1.5 Write Access<http://www.w3.org/2012/01/20-ua-minutes.html#item03>
      4. 2.7.5 <http://www.w3.org/2012/01/20-ua-minutes.html#item04>
      5. 2.3.5 Allow Override of
Accesskeys<http://www.w3.org/2012/01/20-ua-minutes.html#item05>
      6. 2.2.4 Options for Wrapping in
Navigation<http://www.w3.org/2012/01/20-ua-minutes.html#item06>
      7. 2.2.2 Sequential Navigation Between
Viewports<http://www.w3.org/2012/01/20-ua-minutes.html#item07>
      8. 1.11.2 Extended Link
Information<http://www.w3.org/2012/01/20-ua-minutes.html#item08>
      9. 1.7 Guideline 1.7 - Enable Configuration of Style
Profiles<http://www.w3.org/2012/01/20-ua-minutes.html#item09>
   - Summary of Action
Items<http://www.w3.org/2012/01/20-ua-minutes.html#ActionSummary>

------------------------------

<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...
5.4.2 Handle Unrendered Technologies

Jeanne: Might not be accessibility-specific enough.

Jeanne will add to survey proposal to delete it.
5.2.3 Web-Based Accessible (Level AAA)

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].
4.1.5 Write Access

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)
2.7.5

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 Allow Override of Accesskeys

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].
2.2.4 Options for Wrapping in Navigation

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.
2.2.2 Sequential Navigation Between Viewports

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].
1.11.2 Extended Link Information

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.
1.7 Guideline 1.7 - Enable Configuration of Style Profiles

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
 Summary of Action Items *[NEW]* *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]
*[NEW]* *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
]
*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]

[End of minutes]
------------------------------


-- 
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964