User Agent Accessibility Guidelines Working Group Teleconference -- 26 Feb 2010

<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: 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 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

<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> 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 - http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0090.html

<jeanne2> 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 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 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> http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0089.html

<jallan> 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 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 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> 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> 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 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) 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 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> 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> 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> 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.

* Intent of Success Criterion 5.4.x:

* Examples of 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 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 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".

<jallan> KF: new browser... twitter ... the most popular twitter cllient for screen reader user is 'qwitter' , it has no UI, and will not meet accessibility standards.

<jallan> GL: rebuttal, uaag create browsers usable by as many people as possible. a nitch browser should be able to have some compliance with a caveat for saying UAx is accessible to this class of people but not to low vision.

<jallan> concept of partial compliance. UA does x, y, z ... will work very well for folks who are blind but not others

<jallan> JA: is that possible use technology exclusion.

<jallan> should have an informal list for how SC match up with specific disbabilities with personas and scenarios for use cases (non-normative)

<jallan> any concerns about specialized browsers not getting conformance.

<jallan> ACTION: JS to write list of questions for feedback in the status section of new draft. add specialized browser conformance (partial conformance) this includes AT [recorded in http://www.w3.org/2010/02/26-ua-minutes.html#action07]

<trackbot> Created ACTION-318 - Write list of questions for feedback in the status section of new draft. add specialized browser conformance (partial conformance) this includes AT [on Jeanne Spellman - due 2010-03-05].

<jallan> does the user community want this???

<jallan> if not then we will drop it.

<jallan> what about a mainstream browser tries for partial conformance.

<jallan> want to reward folks for doing things right while pointing out the deficits.

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

26 Feb 2010

Attendees

Contents

review of morning's work

definition of 'focus' 3.11

3.10 implementions

Conformance

principle 5

Principle 1

Summary of Action Items

Scribe.perl diagnostic output