- From: Jeanne Spellman <jeanne@w3.org>
- Date: Fri, 26 Feb 2010 16:01:03 -0600
- To: User Agent Working Group <w3c-wai-ua@w3.org>
Minutes:
http://www.w3.org/2010/02/26-ua-minutes.html
IRC Log:
http://www.w3.org/2010/02/26-ua-irc
Text of Minutes
[1]W3C
[1] http://www.w3.org/
- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
26 Feb 2010
See also: [2]IRC log
[2] http://www.w3.org/2010/02/26-ua-irc
Attendees
Present
Greg_Lowney, Jeanne_Spellman, Jim_Allan, Kim_Patch,
Mark_Hakkinen, Simon_Harper, Kelly_Ford
Regrets
Patrick_Lauke
Chair
Jim_Allan, Kelly_Ford
Scribe
jallan, greg
Contents
* [3]Topics
1. [4]review of morning's work
2. [5]definition of 'focus' 3.11
3. [6]3.10 implementions
4. [7]Conformance
5. [8]principle 5
6. [9]Principle 1
* [10]Summary of Action Items
_________________________________________________________
<trackbot> Date: 26 February 2010
<jeanne2> trackbot, start meeting
<trackbot> Meeting: User Agent Accessibility Guidelines Working
Group Teleconference
<trackbot> Date: 26 February 2010
<jeanne2> Meeting: User Agent Working Group Face to Face Day 2
<kford> Morning, you all have a lite night in Texas there or what
<smile>
<kford> can someone paste the url to the working draft.
<greg> The group is dividing into pairs to continue working on
Implementing details for 3.x
<kford> Yesterday's writing
<kford> Jeanne capturing in document.
<kford> MH I'll start on 3.6.1 if you want to do 3.6.2.
<jeanne2> Old Editors draft with reference to UAAG 1 checkpoints:
[11]http://www.w3.org/WAI/UA/2008/WD-UAAG20-20081120/Overview.html
[11] http://www.w3.org/WAI/UA/2008/WD-UAAG20-20081120/Overview.html
<kford> 3.10.7 and 3.10.8 viewport on request and viewports do not
grab focus
<kford> Intent:
<kford> Unexpected focus and viewport changes can be disorienting
for all users, requiring time and effort for the user to orient to
the change. These success criteria are intended to allow the user to
be in control of when viewport changes happen so the user can orient
to the changes in a predictable fashion.
<kford> Example:
<kford> A web page is loaded in the browser that triggers a
secondary page (typically known as a pop-up) to open. The user agent
presents the user with the initial page requested and an alert that
additional content is available. The user can choose to have this
pop-up content shown or not, remaining in control of what is
displayed in the user agent’s viewport. A user agent may also be
configured...
<kford> ...so that pop-ups do open automatically because the user
has chosen to automatically have this content available. The user
has a setting however to configure pop-ups such that they open in
the background. Hence when visiting a web page with this secondary
content, focus remains in the primary viewport with the initial page
content requested. The user agent alerts the user that secondary...
<kford> ...content is available in another viewport and the user can
activate this viewport on request, perhaps with a click on the
notification mechanism.
<kford> 3.10.9 viewport on top
<kford> Intent:
<kford> The purpose of this item is to ensure that the active
viewport is always available to the user due to the multiple ways
the user may be accessing it. Assistive technology for example keys
off of the foreground window to report what is happening to the end
user.
<kford> Example:
<kford> The user agent has multiple viewports to convey the status
of what is happening. A filedown may be happening and status
displayed in one viewport while a web page is being read in a
second. The user wants to determine the file download status so
switches to this viewport. The viewport becomes the top most window
in the user agent.
<kford> Example:
<kford> The user agent has multiple viewports to convey the status
of what is happening. A file download may be in progress with status
displayed in one viewport while a web page is being read in a
second. The user wants to determine the file download status so
switches to the viewport displaying the file download status. The
viewport becomes the top most window in the user agent.
<kford> 3.10.10 close viewport
<kford> Intent: Put the user in control of what viewports the user
agent has opened.
<kford> Example:
<kford> A user has multiple viewports open and is finished viewing
content in one or many of them. The user can easily close these
viewports, reducing potential distractions from having undesired
viewports in the browsing environment.
<kford> 3.10.11 Same UI
<kford> Intent:
<kford> Users orient themselves to a browsing environment with a
variety of techniques. This success criteria is designed to ensure
that the user does not have to learn multiple strategies to use the
browsing viewport.
<kford> Example:
<kford> An individual using magnification software may know that web
content begins one inch from the top of the screen in the user agent
and has magnification software configured to present content
starting at this location. Offering the ability to have all
viewports open with the same user interface means the user can
quickly focus on the web content of interest without having to
orient to...
<kford> ...different environments each time a viewport opens.
<kford> 3.10.12 Viewport Position
<kford> Intent:
<kford> This criteria targets the ability for a user to easily
understand where they are located relative to the total content
available for rendering.
<kford> Example:
<kford> A user is reading through a web page and a scroll bar makes
it possible to easily determine how much content has been read and
how much remains to be read.
<mhakkinen> 3.10.1 Highlight Viewport: The viewport with the current
focus is highlighted (including any frame that takes current focus)
using a highlight mechanism that does not rely on rendered text
foreground and background colors alone (e.g., a thick outline).
(Level A)
<mhakkinen> Intent of Success Criterion 3.10.1
<mhakkinen> When a user agent presents content using multiple
viewports, users benefit from a clear indication of which viewport
has focus. Simply relying upon text foreground and background colors
to indicate focus may not provide sufficient, visually perceivable
indication for users with low vision. Highlighting of viewport
frames using both color, with sufficient contrast, and increase in
viewport border thickness can provide multiple visual cues that
indicate
<mhakkinen> focus.
<mhakkinen> Examples of Success Criterion 3.10.1
<mhakkinen> A music Web site allows the user to select which of the
top 10 songs are available for listening. Each song is presented in
a graphical viewport providing a music player. Using a keyboard
based screen magnification tool, a low vision user tabs between
songs, with the currently selected player viewport highlighted with
a thick, yellow border against a dark grey background.
<mhakkinen> 3.10.2 Move Viewport to Selection: When a viewport's
selection changes, the viewport moves as necessary to ensure that
the new selection is at least partially in the viewport. (Level A)
<mhakkinen> Intent of Success Criterion 3.10.2
<mhakkinen> When content is presented within a viewport and the
content extends horizontally or vertically beyond the visible bounds
of the viewport, the user must be able to move to a selectable
element or elements which may be out of view, and to have the
selected content automatically move into view. For keyboard based
users and users of screen magnification tools, this allows users an
efficient means to view selected content without having to utilize
scrolling
<mhakkinen> controls to locate and view the selection.
<mhakkinen> Examples of Success Criterion 3.10.2
<mhakkinen> A screen magnification user is performing a spell check
of a blog posting that is contained within a scrollable viewport.
The text of the blog posting exceeds the vertical size of the
viewport. The blogging software provides a key to move to the first,
and then any subsequent, unrecognized words. With two unrecognized
words in the posting, the user ignores the first selected word, and
presses the keystroke to move to the next which is currently out of
<mhakkinen> view in the last sentence of the posting. As the key is
pressed, the viewport scrolls to show the selected word.
<mhakkinen> 3.10.3 Move Viewport to Focus: When a viewport's content
focus changes, the viewport moves as necessary to ensure that the
new content focus is at least partially in the viewport. (Level A)
<mhakkinen> Intent of Success Criterion 3.10.3
<mhakkinen> When content is presented within a viewport and the
content extends horizontally or vertically beyond the visible bounds
of the viewport, the user must be able to move to any focusable
elements which may be out of view, and to have the element receiving
focus automatically move into view. For keyboard based users and
users of screen magnification tools, this allows users an efficient
means to view a focused element without having to utilize scrolling
<mhakkinen> controls to locate and view the element with focus.
<mhakkinen> Examples of Success Criterion 3.10.3
<mhakkinen> A user of a screen reader is showing a sighted colleague
how to complete a registration form contained within a viewport. The
form exceeds the veritical bounds of the viewport, requiring
vertical scrolling to view the complete form content. As the screen
reader completes each form entry and presses the tab key, the next
form control in the tab order scrolls into view if it is not already
visible in the viewport.
<mhakkinen> 3.10.4 Resizable: The user has the option to make
graphical viewports resizable, within the limits of the display,
overriding any values specified by the author. (Level A)
<mhakkinen> Intent of Success Criterion 3.10.4
<mhakkinen> If a graphical viewport contains complex content that
exceeds the dimensions of the viewport, users should have the option
to increase the size of the viewport to allow the full image to be
displayed without scrolling, within the limits of the physical
display screen. This benefits users keyboard users who may find it
difficult to scroll content and users with cognitive or learning
disabilities whose understanding of the content is aided by being
able
<mhakkinen> to view the complete image.
<mhakkinen> Examples of Success Criterion 3.10.4
<mhakkinen> A viewport is used to display an image depicting an
orgnaization chart. A user with a learning disability cannot
maintain a mental representation of the organizational linkages for
items out of view. In order to facilitate their understanding of the
organization, the user drags the sizing icon on the corners of the
viewport to allow the entire chart to be displayed.
<mhakkinen> re-edit of intent & example:
<mhakkinen> Intent of Success Criterion 3.10.4
<mhakkinen> If a graphical viewport contains content that exceeds
the dimensions of the viewport, users should have the option to
increase the size of the viewport to allow the full image to be
displayed without scrolling, within the limits of the physical
display screen. This benefits keyboard users who may find it
difficult to scroll content and users with cognitive or learning
disabilities whose understanding of the content is aided by being
able to view the
<mhakkinen> complete image.
<mhakkinen> Examples of Success Criterion 3.10.4
<mhakkinen> A viewport is used to display an image depicting an
organization chart. A user with a learning disability has difficulty
maintaining a mental representation of the organizational linkages
for items out of view. In order to facilitate their understanding of
the organization, the user drags the sizing icon on the corners of
the viewport to allow the entire chart to be displayed.
<mhakkinen> 3.10.5 Scrollbars: Graphical viewports include
scrollbars if the rendered content (including after user preferences
have been applied) extends beyond the viewport dimensions,
overriding any values specified by the author. (Level A)
<mhakkinen> Intent of Success Criterion 3.10.5
<mhakkinen> When rendered content exceeds the horizontal and/or
vertical bounds of a graphical viewport, scrollbars provide an
visible indication that not all of the rendered content is currently
visible within the viewport. The scrollbars provide indication to
users who may not be able to otherwise recognize that the rendered
content is not fully visible.
<mhakkinen> Examples of Success Criterion 3.10.5
<mhakkinen> A Web site presents a recipe within a viewport, and the
length of the recipe exceeds the vertical and horizontal dimension
of the viewport, though the step by step graphical depiction of the
recipe does not make this obvious. A user following the recipe, uses
the scroll bar to recognize that additional steps may be present,
and scrolls them into view.
<kford> Simon, just so you know we've been writing some intent and
such. Mark and I are working over skype and phone. Feel free to
comment on Mark's example.
<Kim> link for greg
[12]http://docs.google.com/Doc?docid=0ASiGLIaAlHSKZGR3d3FrbWJfMjMzZH
JtemhuY3o&hl=en
[12]
http://docs.google.com/Doc?docid=0ASiGLIaAlHSKZGR3d3FrbWJfMjMzZHJtemhuY3o&hl=en
<mhakkinen> edit of 3.10.5 Intent & Example:
<mhakkinen> Intent of Success Criterion 3.10.5
<mhakkinen> When rendered content exceeds the horizontal and/or
vertical bounds of a graphical viewport, scrollbars provide a
visible indication that not all of the rendered content is currently
visible within the viewport. The scrollbars provide indication to
users who may not be able to otherwise recognize that the rendered
content is not fully visible.
<mhakkinen> Examples of Success Criterion 3.10.5
<mhakkinen> A Web site presents a recipe within a viewport, and the
length of the recipe exceeds the vertical and horizontal dimension
of the viewport, though the step by step graphical depiction of the
recipe does not make this obvious. A user following the recipe, uses
the scroll bar to recognize that additional steps may be present,
and scrolls them into view.
<kford> 3.10.12 Viewport Position revised example
<kford> Intent:
<kford> This criteria targets the ability for a user to easily
understand where they are located relative to the total content
available for rendering and the amount of content relative to the
total being displayed.
<kford> Example:
<kford> A user navigates to a lengthy web page and begins paging
through the content. A scroll bar visually indicates the position
within the content as the user pages and also that with each paging
action only a small portion of the content is being rendered.
Another user accesses this web page with a screen reader and has the
percentage that the page is scrolled communicated by the screen
reader...
<kford> ...because the user agent makes information from the scroll
bar available programmatically.
<kford> And a revised close.
<kford> 3.10.10 close viewport revised example
<kford> Intent: Put the user in control of what viewports the user
agent has opened.
<kford> Example:
<kford> A user has multiple viewports open such as from a user agent
that supports tabbed browsing and is finished viewing content in one
or many of them. The user activates a close button on the viewports
that are to be closed and they are closed by the user agent. This
reduces distractions from undesired viewports being opened for the
user.
<jallan> discussion meeting last evening
<jallan> SH: perhaps a list of extensions or other tools that
provide for accessibility (taking up the slack) for what base UAs
are not providing.
<jallan> most folks did not get what user agents do for
accessibility. they were focused on broader issues
review of morning's work
<jeanne2>
[13]http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100
226.html
[13]
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100226.html
<greg> Mark and Kelly worked on 3.10; Jim worked on 3.6; Kim and
Greg worked on definitions related to 3.11; Jeanne worked on
integrating yesterday's changes into the draft document.
definition of 'focus' 3.11
<jallan> lack of definitions
<jallan> all is reconciled, used some ISO definitions, and some old
UAAG10 definitions
<jallan> all new definitions -
[14]http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0090.h
tml
[14]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0090.html
<jeanne2>
[15]http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100
226.html#def-focus
[15]
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100226.html#def-focus
<jallan> we need to reword definitions from ISO
<jallan> proposing to use the reworded definition set from ISO
<jallan> proposed: delete content focus definition
[16]http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100
226.html#def-focus
[16]
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100226.html#def-focus
<jeanne2> I want to be clear that we can make sure that we are not
in conflict with the ISO definitions, but we cannot use the ISO
definitions.
<jallan> new definitions are more operationally defined.
<jallan> issue: editorial--review document for normalization of
terms that match new definition
<trackbot> Created ISSUE-66 - Editorial--review document for
normalization of terms that match new definition ; please complete
additional details at
[17]http://www.w3.org/WAI/UA/tracker/issues/66/edit .
[17] http://www.w3.org/WAI/UA/tracker/issues/66/edit
<jallan> scribe: jallan
SH: some of the definitions overlap
... different kinds of focus, how you get to it or use it. and that
cursor, pointer, and caret are different things.
GL: these are a hierarchy, but not written that way yet.
SH: the pointers are defined by their interaction type. instead of
conflating focuses and cursor, discuss each separately.
... really suggesting grouping.
KP: is this a good direction?
JS: good to use similar terms, and normalize definitions.
KP: need to group and put in hierarchy. Keyboard focus was in the
document but not defined.
<jeanne2> +1
<kford> I think the proposal is fine.
all present agree with dropping the definition.
scribe: GL wants to pass it by the entire group. add to a survey for
next week.
... 3.11.x implementation not yet done. now that the terms are
defined implementation writing will be easier. some SC may need to
be rewritten based on new definitions.
3.10 implementions
<scribe> scribe: greg
<jallan>
[18]http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0089.h
tml
[18]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0089.html
<jallan>
[19]http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0088.h
tml
[19]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0088.html
MH: Questioned whether Back button is an accessibility issue.
JA: Back button important for users with cognitive impairments, and
usability issue particularly important for people for whom
navigating within the page is difficult.
General agreement to keep 3.6 (Back button).
JA: It was 9.4 in UAAG 1.0, discussed in Techniques.
Draft techniques for 3.10.1 through 3.10.5 (from Jim) and 3.10.7
through 3.10.8 (from Kelly) were sent in email and will be put into
the survey for next week.
Correction, 3.10.7 through 3.10.12 from Kelly.
<mhakkinen> correction 3.10.1 through 3.10.5 from Mark
JA: While an SC required allowing font size differences to be
preserved during zoom, but nothing required zoom.
<jallan> ACTION: jallan to write sc for allow user to scale text and
images [recorded in
[20]http://www.w3.org/2010/02/26-ua-minutes.html#action01]
<trackbot> Created ACTION-312 - Write sc for allow user to scale
text and images [on Jim Allan - due 2010-03-05].
<kford> /me I am back.
JA: 3.6.4 (Maintain contrast) is nice but doubts any UA will
implement it.
Greg: Could be relatively easily implemented as an add-in.
GL: the user can accomplish nearly the same thing by turning off all
author-specified colors, but that's the "big hammer" approach.
KF: More of a wish-list item.
MH: Definitely doable.
JA: Nice but seems low on the priority list.
JS: Contrast is the largest issue for users with vision difficulties
related to albinism; it would be a big benefit to them.
General agreement to remove it, as good but not compelling.
Resolution: remove 3.6.4 (Maintain Contrast)
<jeanne2> ACTION: jeanne to remove SC 3.6.4 (Maintain Contrast) from
draft. [recorded in
[21]http://www.w3.org/2010/02/26-ua-minutes.html#action02]
<trackbot> Created ACTION-313 - Remove SC 3.6.4 (Maintain Contrast)
from draft. [on Jeanne Spellman - due 2010-03-05].
Conformance
JA: The remainder of his items posted to the list.
<jeanne2>
[22]http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100
226.html#conformance
[22]
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100226.html#conformance
GL: Noted that we have not yet addressed the issue that Conformance
Requirements don't allow exceptions for inapplicability.
<jallan>
[23]http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0077.h
tml
[23]
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0077.html
<jeanne2> ACTION: jeanne to draft a section of Conformance dealing
with Not Applicable. See the email from Greg 2010JanMar/0077.html
[recorded in
[24]http://www.w3.org/2010/02/26-ua-minutes.html#action03]
<trackbot> Created ACTION-314 - Draft a section of Conformance
dealing with Not Applicable. See the email from Greg
2010JanMar/0077.html [on Jeanne Spellman - due 2010-03-05].
JA: UAAG1 allowed conformance on with "conformance profiles",
subsets such as audio, video, selection, keyboard input. No browser
developer ever filed a conformance claim, so there was no feedback
on the value of this approach.
<jeanne2> GL: there are two approaches for handling exclusions: 1)
is to have the claimant list everything that they are exempt from,
or 2) reword all the SC to qualify that "For those User Agents that
produce speech output..."
GL: As yet undecided whether formal conformance claims will be
required (as with WCAG) or optional (as with ATAG). Note that W3 had
no method of monitoring.
Correction: That was JA.
<jallan> UAAG10 has implementation reports (closest thing to
conformance claim) [25]http://www.w3.org/WAI/UA/impl-pr2/
[25] http://www.w3.org/WAI/UA/impl-pr2/
SH: Not in favor of making it optional, but would be OK to have it
included in product documents.
GL: Current wording requires a URI for the claim, so it must be on
the Web, not be just in the product documentation.
SH: Concerned by requirement to list supported technologies (as
Kelly expressed yesterday).
<jallan> 3 categories. included - UA supports in accessible way;
excluded - ua supports in inaccessible way, and not supported - UA
does not support at all.
<jallan> SH: could a UA claim conformance but exclude HTML
<jallan> GL: if a UA supports something, then you must include or
exclude it
<jallan> JS: canvas, UA XYZ, does not support canvas accessibly.
<jallan> JA: canvas is part of html5, if a UA supports HTML5, can a
claim exclude a specific element (canvas), seems a slippery slope.
<jallan> GL: guideline 1 says must implement full features of
published standards
<jallan> KF: can't blanket statement
<jallan> UA supports all 4.01, no UA does
<jallan> SH: UA could claim conformance for 4.01, but exclude HTML5?
<jallan> JS: propose item 5 & 6 of conformance (included & excluded
technologies) be removed.
<jeanne2> JA: I think the technologies which are really different,
they are much larger than the elements of the HTML. "I support HTML,
but not Canvas". You either support HTML and support it accessibly,
or not.
JA: Feels that listing Included or Excluded technologies is
different from included or excluded elements (e.g. specific CSS
attributes). Would prefer to just say that a product supports or
fails to support a larger tech such as HTML 4.01 in an accessible
way.
<jallan> JA: can include/exclude technology. but UA would say 'fail
SC xxx, because yyy element is not accessible'
<jallan> ... this is different from excluding an element. don't want
to go there.
<jallan> GL: discusses major and minor features of a UA, the major
parts should be accessible
<jallan> GL: conformance is a can of worms
<jallan> +1 all around
<jallan> KP: can claim conformance by stating a collection of
technologies.
<jallan> JS: yes, item 4
<jallan> GL: surely the UA does not have to file a separate
conformance claim for each extension...
<jeanne2> ACTION: JS to reword #4 of Required Components to clarify
that the information provided for each collection of components is
simply the name, vendor, version #, etc. [recorded in
[26]http://www.w3.org/2010/02/26-ua-minutes.html#action04]
<trackbot> Created ACTION-315 - Reword #4 of Required Components to
clarify that the information provided for each collection of
components is simply the name, vendor, version #, etc. [on Jeanne
Spellman - due 2010-03-05].
<jallan> JS: no, just file one claim and list all technologies
included
<jallan> MH: what if there are conflicting conformance claims.
<jallan> KF: don't see as an issue. more important as to who is
making the claim.
<jallan> ... style sheets, claim conformance, what should I say. UA
XYZ supports style sheet because, user can choose two different
sheets.
<jallan> JA: conformance claim vs implementation report. need
testing tools, etc.
<jeanne2> [27]http://www.headstar.com/eablive/?p=397
[27] http://www.headstar.com/eablive/?p=397
<jallan> scribe: jallan
<scribe> scribe: greg
Discussion of whether/how we should pursue HTML5 issues.
MH: If we comments on or raises concerns about HTML5 Video, should
he do it as a member of UAWG or as an individual?
principle 5
<kford> Zakim: Sorry, can someone paste the link to the doc again?
<jeanne2>
[28]http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100
226.html
[28]
http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100226.html
<kford> Here is some text for 5.3.5 and 5.3.x. Anyone care to
comment?
<kford> Here is some text for 5.3.5 and 5.3.x. Anyone care to
comment?
<kford> 5.3.5 Context Sensitive Help: There is context-sensitive
help on all user agent features that benefit accessibility. (Level
AAA)
<kford> Intent:
<kford> The purpose of this criteria is to help maximize the
discovery of user agent features that benefit accessibility.
<kford> Example:
<kford> A user is exploring the menus of a user agent and finds a
feature named Use My Style Sheet. Activating help the user quickly
learns that this feature allows custom CSS stylesheets to be created
to help make web content more accessible.
<kford> 5.3.x Appropriate Language If characteristics of your user
agent involve producing an end user experience such as speech, you
need to react appropriately to language changes.
<kford> Intent:
<kford> The goal of this criteria is to ensure that user agents
present spoken web content with in the language appropriate to the
content as indicated by the lang attribute. Authors use this tag to
indicate the language of content.
<kford> Example:
<kford> A user agent has a feature to read web pages verbally using
synthetic speech. A user is browsing a web site devoted to language
translation. As the browser is speaking the content of the page, the
synthetic speech switches to the language of the content, using
appropriate pronunciation and related characteristic’s for the
language.
<jeanne2> 5.2.1 Form Submission: The user has the option to confirm
(or cancel) any form submission made while content focus is not on
the submitting control (e.g., forms that submit when Enter is
pressed). (Level AA)
<jeanne2> proposed: The user has the ability to set a global option
disable any form submission made by a control that is not the submit
control (e.g. forms that submit when Enter is pressed). Should login
be an exception?
<jeanne2> Intent:
<jeanne2> Users need to be protected against accidently submitting a
form. Some assistive technologies use the Enter key to advance to
the next field. If the form is designed to submit on Enter, the user
can unknowingly submit the form. Those users need to be able to
disable the ability to submit on Enter.
<jeanne2> Example:
<jeanne2> Upon installation of a web browser, a screenreader user
selects an option to disable form submission on Enter. This is a
preference option that can be easily discovered and changed by the
user in the future. This allows the user to complete forms from the
banking website knowing that the submit button must be selected in
order to submit the form.
<jallan> 5.3.3 Changes Between Versions: Changes to features that
affect accessibility since the previous version of the user agent
are documented. (Level AA)
<jallan> # Intent of Success Criterion 5.3.3
<jallan> As accessessibility features are implemented in new
versions it is important for users to be able to be informed about
these new features and how to operate them. The user should not have
to discover which new features were implemented in the new version.
<jallan> # Examples of Success Criterion 5.3.3
<jallan> In this version, we added the ability to display tooltips
on elements with a title attribute when using the keyboard. With
caret browsing turned on simply arrowing onto an element with a
title the tooltip will remain visible while the caret is within the
element.
<jallan> @@should the user be able to set a time limit for how long
a tooltip remains visible? or should they (distraction disorders,
cognitive issues) be able to turn them off all together?
<jallan> 5.3.4 Centralized View: There is a centralized view of all
features of the user agent that benefit accessibility, in a
dedicated section of the documentation. (Level AA)
<jallan> # Intent of Success Criterion 5.3.4
<jallan> Specific accessibility features are important for users to
know about and how to operate. The user should not have to discover
where the accessibility features are documented in context (although
that too is very useful). A specific section devoted to only
accessibililty features (eg. keyboard shortcuts, how to zoom the
viewport, where to find accessibility configuration settings),
would...
<jallan> ...would make it easier for user to become more functional
more quickly with the user agent.
<jallan> # Examples of Success Criterion 5.3.4
<jallan> A specific section in the documentation (local or online)
detailing accessibility features of the user agent.
<jallan> @@what about accessibility features of plugins, extensions,
etc. they are not user agents by them selves. how do user find out
about accessibility features if any in the extension?
<mhakkinen> 5.3.1 Accessible Format: At least one version of the
documentation is either (Level A):
<mhakkinen> (a) "A" accessible: Web content and conforms to WCAG 2.0
Level "A" (although it is not necessary for the documentation to be
delivered on-line), or,
<mhakkinen> (b) accessible platform format: not Web content and
conforms to a published accessibility benchmark that is identified
in the conformance claim (e.g., when platform-specific documentation
systems are used).
<mhakkinen> Intent of Success Criterion 5.3.1:
<mhakkinen> User agents will provide documentation in a format that
is accessible. If provided as Web content, it must conform to WCAG
2.0 Level "A" and if not provided as Web content, it must be in
conformance to a published accessibility benchmark and identified in
any conformance claim for the user agent. This benefits all users
who utilize assistive technology or accessible formats.
<mhakkinen> Examples of Success Criterion 5.3.1
<mhakkinen> A user agent installs user documentation in HTML format
conforming to WCAG 2.0 Level "A". This documentation is viewed
within the user agent and is accessible in accordance with the
conformance of the user agent to UAAG 2.0.
<mhakkinen> A user agent provides documentation in HTML format
conforming to WCAG 2.0 Level "AA" and is available online. In
addition, the user agent provides user documentation in a locally
installed digital talking book content format in conformance with a
recognized, published format.
<Kim> 5.1.1 Option to Ignore
<Kim> Intent of Success Criterion 5.1.1:
<Kim> Messages designed to inform the user can be a burden to users
for whom keypress is time-consuming, tiring, or painful. It's
important that these users be able to turn off unnecessary messages.
<Kim> Examples of Success Criterion 5.1.1:
<Kim> The browser has an update ready. The user should have the
option to be informed of an update or, instead, only get update
information when the user actively requests it.
<mhakkinen> 5.3.2 Document Accessibility Features: All user agent
features that benefit accessibility @@DEFINE - as specified in the
conformance claim@@ are documented. (Level A)
<mhakkinen> Intent of Success Criterion 5.3.2:
<mhakkinen> User agent documentation that includes listings and
descriptions of features supporting or benefitting accessibility
permits users to have access to a description of the accessibility
and compatibility features. This benefits all users with
disabilities who may require assistance in identifying which
accessibility features may be present or how to configure those
features to work with assistive technology.
<mhakkinen> Examples of Success Criterion 5.3.2:
<mhakkinen> In a section entitled "Browser Features Supporting
Accessibility", a vendor provides a detailed description of user
agent features provide accessibility, describing how they function,
and listing any supported third party assistive technologies that
may be supported or required.
Suggested rewrite of 5.4.1:
5.4.1 The user has a global option to disable recognized mechanisms
used by web pages to specify default focus.
(@@ Issue: Is there a *recognized* way to set the default focus? Or
are we expecting the user agent to block all javascript attempts to
set the keyboard focus, or during initial page load? Or should we
remove this and delegate to WCAG 2.4.3. If the UA blocks all
attempts to move focus, would that break pages?)
* Intent of Success Criterion 5.4.x:
Users need to know that navigation in a web page is going to start
in a predictable location. While we recognize that it may be
desirable for accessibility to set focus to specific link on a page
other than the first link, the user needs to be in control of this
feature.
* Examples of Success Criterion 5.4.x:
o Example: the page has a default focus to search box, the user has
to take additional scrolling or navigation to get to the content
that was not in the search box. The user may want to set their page
so it follows the default behavior of starting with the keyboard
input focus at the top of the page, starts at the first link, rather
than not the search box.
o Example: The user loads a page that contains instructions followed
by a form. If the page automatically moves the keyboard focus to the
form, a user relying on a screen reader or screen enlarger may not
realize there were instructions. To avoid this problem, the user
sets an option to prevent default focus changes.
* Related Resources for Success Criterion 5.4.x:
o NA
Ignore that, it included all the deleted text. Trying again:
Suggested rewrite of 5.4.1:
5.4.1 The user has a global option to disable recognized mechanisms
used by web pages to specify default focus.
(@@ Issue: Is there a *recognized* way to set the default focus? Or
are we expecting the user agent to block all javascript attempts to
set the keyboard focus, or during initial page load? Or should we
remove this and delegate to WCAG 2.4.3. If the UA blocks all
attempts to move focus, would that break pages?)
* Intent of Success Criterion 5.4.x:
Users need to know that navigation in a web page is going to start
in a predictable location. While we recognize that it may be
desirable for accessibility to set focus to specific link on a page
other than the first link, the user needs to be in control of this
feature.
* Examples of Success Criterion 5.4.x:
o Example: the page has a default focus to search box, the user has
to take additional scrolling or navigation to get to the content
that was not in the search box. The user may want to set their page
so it follows the default behavior of starting with the keyboard
input focus at the top of the page, rather than the search box.
o Example: The user loads a page that contains instructions followed
by a form. If the page automatically moves the keyboard focus to the
form, a user relying on a screen reader or screen enlarger may not
realize there were instructions. To avoid this problem, the user
sets an option to prevent default focus changes.* Related Resources
for Success Criterion 5.4.x:
o NA
Minor edit of 5.4.2 plus new intent and examples:
5.4.2 Unpredictable focus: Don't move the focus without telling the
user, and provide a global option to block focus changes that are
not initiated by the user.
* Intent of Success Criterion 5.4.x:
Users can become confused or disoriented when the window scrolls
when they haven't requested it. This is particularly problematic for
users who can only see a small portion of the document, and thus
have to use more effort to determine their new context. Such users
also are more likely to continue typing, not immediately realizing
that the context has changed. Users for whom navigation is t
ime consuming, tiring, or painful (including those using screen
readers or with impaired dexterity) may also need more work to
return to the area where they want to work.
* Examples of Success Criterion 5.4.x:
o A speech user issues a command to execute at a specific location,
and the focus changes without the user's control, so the command
fails or executes with unpredictable results.
o The user is entering a phone number in a form that uses a separate
field for the three-digit area code. When they finish typing the
third digit, the form automatically moves the keyboard focus to the
next field, but the user, not realizing this, is already pressing
the Tab key to move the focus. The result is that the keyboard focus
is moved out of the second field, which is left blank. ...
scribe:
o The users clicks on a button in a form, which recognizes they have
entered invalid data. The page then moves to the keyboard focus to
the field containing the error, and scrolls the window to make that
visible.
* Related Resources for Success Criterion 5.4.x:
o UAAG 2.0 3.10.8 Don't Move Focus
Everyone sent rewrites to the list.
Principle 1
JS would like to work on Implementing details for Principle 1.
GL: Before lunch the major issue was raised of whether requiring
compliance with standards would prevent any UA from conforming,
since few if any are 100% compliant with even widespread standards
such as HTML4 and CSS2.
<jallan> specifically 1.4.1 Follow Specifications: Render content
according to the technology specification. This includes any
accessibility features of the technology.
GL: We have two possible approaches: either reword the SC to not be
so rigidly binding, or else leave the SC and try to weasel out of it
and introduce loopholes in the Implementing document.
Discussion of whether any other standards have such broad
requirements for standards compliance.
<jallan> JS: what if " render content according to features
implemented by the user agent"
JS: Could we not require complete implementation of a spec, but the
portions implemented be accessible?
GL: Might a UA then leave out some portions of HTML or CSS that are
important for accessibility, and still comply?
JS reviews origin of this principle in UAAG 1.0.
<jallan> KF & GL: but a UA could implement all of HTMLx and not
implement the accessibility bits. that is too big of an out
GL: 1.1.1 requires compliance with "Level A" requirements in
standards, but are there any such?
... 1.1.1 seems to require compliance with platform accessibility
standards like MSAA, but that is already required by 2.1.1.
<jallan> GL: where your UI is not based on html, etc comply with
accessibility standards
<jallan> where your UI is based on html, etc comply with WCAG
<jallan> 1.4 is tough, but if a UA is going to support htmlx it
should implement the accessibility bit properly
<jallan> GL drop 1.1, it is redundant to 2.1.1.
<jallan> reword 1.2 - 'webbased UA" user agent UI that is based on
HTML,... change to Web Standards User interface then it needs to
conform to WCAG
<jallan> KF: +1
Suggest rewording 1.2.x to say something like "User agent user
interfaces that are implemented using Web standard technologies
conform to WCAG Level..."
JS: +1
KP: +1
<jallan> +1
<jallan> Proposed: delete GL 1.1 as it is redundant to 2.1
<jallan> MH: iphone app to grab webcontent and present to the user
as a phone app. could be written as standard html, or as iphone
native controls
<jallan> GL: then should say Rendering. "User agent user interfaces
that are rendered using Web standard technologies conform to WCAG
Level..."
<jallan> MH: is rendered sufficient?
<jallan> discussion of rendered vs implemented. we care about how it
is rendered, not actually what the backend is.
<jallan> ACTION: Jeanne to reword GL 1.2 to "User agent user
interfaces that are rendered using Web standard technologies conform
to WCAG Level..." for 1.2.1, 1.2.2, 1.2.3 (wcag a, aa, aaa)
[recorded in
[29]http://www.w3.org/2010/02/26-ua-minutes.html#action05]
<trackbot> Created ACTION-316 - Reword GL 1.2 to "User agent user
interfaces that are rendered using Web standard technologies conform
to WCAG Level..." for 1.2.1, 1.2.2, 1.2.3 (wcag a, aa, aaa) [on
Jeanne Spellman - due 2010-03-05].
<jeanne2> ACTION: JS to add proposals for Principle 5 to document.
5.3.3 to 5.4.x [recorded in
[30]http://www.w3.org/2010/02/26-ua-minutes.html#action06]
<trackbot> Created ACTION-317 - Add proposals for Principle 5 to
document. 5.3.3 to 5.4.x [on Jeanne Spellman - due 2010-03-05].
GL: We are deleting 1.1 because we interpret it as saying that user
agent user interfaces that are not rendered using Web standard
technologies should comply with platform standards for
accessibility....
<jallan> which is 2.1
GL: But, that demonstrates that it is NOT entirely redundant to 2.1,
which only deals with platform standards for communicating with
assistive technology.
... Let's take the example: on Windows it is a platform convention
to put underlined access keys on all menus, menu items, buttons,
etc., that that is clearly a platform convention that benefits
accessibility.
... Therefore any UA running on Windows should comply with that
convention.
... But that should not be limited to UA whose UI is not implemented
using W3 standards.
... Thus, we could rewrite 1.1 along the lines of "User agent user
interfaces comply with standard and/or operating environment
conventions that benefit accessibility."
<jallan> what about refrigerator or TV that has no keyboard, or any
bolt on AT, what are the accessibility requirements. it should have
some kind of UI and virtual keyboard, etc.
GL: In ISO these are covered under a separate set of success
criteria that only apply to "stand-alone systems".
Summary of Action Items
[NEW] ACTION: jallan to write sc for allow user to scale text and
images [recorded in
[31]http://www.w3.org/2010/02/26-ua-minutes.html#action01]
[NEW] ACTION: jeanne to draft a section of Conformance dealing with
Not Applicable. See the email from Greg 2010JanMar/0077.html
[recorded in
[32]http://www.w3.org/2010/02/26-ua-minutes.html#action03]
[NEW] ACTION: jeanne to remove SC 3.6.4 (Maintain Contrast) from
draft. [recorded in
[33]http://www.w3.org/2010/02/26-ua-minutes.html#action02]
[NEW] ACTION: Jeanne to reword GL 1.2 to "User agent user interfaces
that are rendered using Web standard technologies conform to WCAG
Level..." for 1.2.1, 1.2.2, 1.2.3 (wcag a, aa, aaa) [recorded in
[34]http://www.w3.org/2010/02/26-ua-minutes.html#action05]
[NEW] ACTION: JS to add proposals for Principle 5 to document. 5.3.3
to 5.4.x [recorded in
[35]http://www.w3.org/2010/02/26-ua-minutes.html#action06]
[NEW] ACTION: JS to reword #4 of Required Components to clarify that
the information provided for each collection of components is simply
the name, vendor, version #, etc. [recorded in
[36]http://www.w3.org/2010/02/26-ua-minutes.html#action04]
[End of minutes]
Received on Friday, 26 February 2010 22:01:20 UTC