15:02:49 <RRSAgent> RRSAgent has joined #ua
15:02:49 <RRSAgent> logging to http://www.w3.org/2010/02/26-ua-irc
15:02:51 <trackbot> RRSAgent, make logs public
15:02:51 <Zakim> Zakim has joined #ua
15:02:53 <trackbot> Zakim, this will be WAI_UAWG
15:02:53 <Zakim> ok, trackbot; I see WAI_UAWG(F2F)9:30AM scheduled to start 32 minutes ago
15:02:54 <trackbot> Meeting: User Agent Accessibility Guidelines Working Group Teleconference
15:02:54 <trackbot> Date: 26 February 2010
15:05:06 <greg> greg has joined #ua
15:08:10 <jeanne2> jeanne2 has joined #ua
15:08:19 <jeanne2> trackbot, start meeting
15:08:21 <trackbot> RRSAgent, make logs public
15:08:23 <trackbot> Zakim, this will be WAI_UAWG
15:08:23 <Zakim> ok, trackbot; I see WAI_UAWG(F2F)9:30AM scheduled to start 38 minutes ago
15:08:24 <trackbot> Meeting: User Agent Accessibility Guidelines Working Group Teleconference
15:08:24 <trackbot> Date: 26 February 2010
15:08:51 <jeanne2> Meeting: User Agent Working Group Face to Face Day 2
15:09:07 <jeanne2> chair: Jim_Allan, Kelly_Ford
15:09:34 <Zakim> WAI_UAWG(F2F)9:30AM has now started
15:09:40 <Zakim> +[Microsoft]
15:09:51 <kford> zakim, microsoft is kford
15:09:51 <Zakim> +kford; got it
15:10:39 <Zakim> + +1.512.406.aaaa
15:10:44 <kford> Morning, you all have a lite night in Texas there or what <smile>
15:10:57 <jeanne2> zakim, aaaa is really TSBVI
15:10:57 <Zakim> +TSBVI; got it
15:11:11 <jallan> jallan has joined #ua
15:11:24 <jeanne2> zakim, TSBVI has Mark, Jim, Greg, Kim, Jeanne
15:11:24 <Zakim> +Mark, Jim, Greg, Kim, Jeanne; got it
15:11:31 <mhakkinen> mhakkinen has joined #ua
15:13:05 <Kim> Kim has joined #ua
15:14:41 <jeanne2> rrsagent, make minutes
15:14:41 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jeanne2
15:20:48 <kford> can someone paste the url to the working draft.
15:23:08 <greg> The group is dividing into pairs to continue working on Implementing details for 3.x
15:25:47 <kford> Yesterday's writing
15:26:06 <kford> Jeanne capturing in document.
15:26:19 <Zakim> -kford
15:28:06 <kford> MH I'll start on 3.6.1 if you want to do 3.6.2.
15:31:55 <jeanne2> Old Editors draft with reference to UAAG 1 checkpoints: http://www.w3.org/WAI/UA/2008/WD-UAAG20-20081120/Overview.html
16:22:09 <Zakim> -TSBVI
16:22:11 <Zakim> WAI_UAWG(F2F)9:30AM has ended
16:22:12 <Zakim> Attendees were kford, +1.512.406.aaaa, Mark, Jim, Greg, Kim, Jeanne
16:22:37 <jeanne2> rrsagent, make minutes
16:22:37 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jeanne2
16:24:14 <Zakim> WAI_UAWG(F2F)9:30AM has now started
16:24:21 <Zakim> + +1.512.406.aaaa
16:32:10 <kford> 3.10.7 and 3.10.8 viewport on request and viewports do not grab focus
16:32:12 <kford> Intent:
16:32:13 <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.
16:32:15 <kford> Example:
16:32:17 <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...
16:32:18 <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...
16:32:21 <kford> ...content is available in another viewport and the user can activate this viewport on request, perhaps with a click on the notification mechanism.
16:34:14 <kford>  3.10.9 viewport on top
16:34:16 <kford> Intent:
16:34:18 <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.
16:34:19 <kford> Example:
16:34:21 <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.
16:36:10 <kford> Example:
16:36:11 <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.
16:37:43 <kford> 3.10.10 close viewport
16:37:45 <kford> Intent: Put the user in control of what viewports the user agent has opened.
16:37:47 <kford> Example:
16:37:48 <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.
16:39:19 <kford> 3.10.11 Same UI
16:39:20 <kford> Intent:
16:39:22 <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.
16:39:24 <kford> Example:
16:39:26 <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...
16:39:27 <kford> ...different environments each time a viewport opens.
16:42:32 <kford> 3.10.12 Viewport Position
16:42:33 <kford> Intent:
16:42:35 <kford> This criteria targets the ability for a user to easily understand where they are located relative to the total content available for rendering.
16:42:36 <kford> Example:
16:42:38 <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.
16:50:24 <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) 
16:50:24 <mhakkinen> Intent of Success Criterion 3.10.1 
16:50:24 <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
16:50:26 <mhakkinen> focus. 
16:50:28 <mhakkinen> Examples of Success Criterion 3.10.1 
16:50:30 <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. 
16:51:53 <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) 
16:51:53 <mhakkinen> Intent of Success Criterion 3.10.2 
16:51:53 <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
16:51:54 <mhakkinen> controls to locate and view the selection. 
16:51:56 <mhakkinen> Examples of Success Criterion 3.10.2 
16:51:58 <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
16:52:03 <mhakkinen> view in the last sentence of the posting. As the key is pressed, the viewport scrolls to show the selected word. 
16:53:18 <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) 
16:53:18 <mhakkinen> Intent of Success Criterion 3.10.3 
16:53:18 <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
16:53:19 <mhakkinen> controls to locate and view the element with focus. 
16:53:21 <mhakkinen> Examples of Success Criterion 3.10.3 
16:53:23 <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. 
16:56:03 <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) 
16:56:04 <mhakkinen> Intent of Success Criterion 3.10.4 
16:56:04 <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
16:56:04 <mhakkinen> to view the complete image. 
16:56:06 <mhakkinen> Examples of Success Criterion 3.10.4 
16:56:09 <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. 
16:59:23 <mhakkinen> re-edit of intent & example:
16:59:23 <mhakkinen>  Intent of Success Criterion 3.10.4 
16:59:23 <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
16:59:23 <mhakkinen> complete image. 
16:59:25 <mhakkinen> Examples of Success Criterion 3.10.4 
16:59:27 <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. 
17:12:24 <sharper> sharper has joined #ua
17:13:22 <sharper> zakim, code?
17:13:22 <Zakim> the conference code is 0225 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), sharper
17:15:01 <Zakim> +??P0
17:15:09 <sharper> zakim, ??P0 is sharper
17:15:09 <Zakim> +sharper; got it
17:18:37 <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) 
17:18:37 <mhakkinen> Intent of Success Criterion 3.10.5 
17:18:37 <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. 
17:18:37 <mhakkinen> Examples of Success Criterion 3.10.5 
17:18:39 <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. 
17:18:54 <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.
17:21:41 <Kim> link for greg http://docs.google.com/Doc?docid=0ASiGLIaAlHSKZGR3d3FrbWJfMjMzZHJtemhuY3o&hl=en
17:21:45 <mhakkinen> edit of 3.10.5 Intent & Example:
17:21:45 <mhakkinen> Intent of Success Criterion 3.10.5 
17:21:45 <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. 
17:21:45 <mhakkinen> Examples of Success Criterion 3.10.5 
17:21:46 <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. 
17:22:40 <kford> 3.10.12 Viewport Position revised example
17:22:41 <kford> Intent:
17:22:43 <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.
17:22:45 <kford> Example:
17:22:46 <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...
17:22:48 <kford> ...because the user agent makes information from the scroll bar available programmatically.
17:23:38 <kford> And a revised close.
17:23:42 <kford> 3.10.10 close viewport revised example
17:23:44 <kford> Intent: Put the user in control of what viewports the user agent has opened.
17:23:46 <kford> Example:
17:23:47 <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.
17:24:31 <Zakim> +[Microsoft]
17:24:48 <kford> zakim, microsoft is kford
17:24:48 <Zakim> +kford; got it
17:28:50 <jallan> discussion meeting last evening
17:29:35 <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.
17:31:08 <jallan> most folks did not get what user agents do for accessibility. they were focused on broader issues
17:31:25 <jallan> rrsagent, make minutes
17:31:25 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jallan
17:32:36 <greg> topic: review of morning's work
17:32:43 <jeanne2> http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100226.html
17:33:50 <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.
17:36:16 <jeanne2> present+ Simon_Harper
17:37:14 <jallan> Topic: definition of 'focus' 3.11
17:37:42 <jallan> lack of definitions
17:38:05 <jallan> all is reconciled, used some ISO definitions, and some old UAAG10 definitions
17:38:36 <jallan> all new definitions - http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0090.html
17:40:03 <jeanne2> http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100226.html#def-focus
17:40:41 <jeanne2> rrsagent, make minutes
17:40:41 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jeanne2
17:41:48 <jallan> we need to reword definitions from ISO
17:43:39 <jallan> proposing to use the reworded definition set from ISO
17:44:48 <jallan> proposed: delete content focus definition http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100226.html#def-focus
17:45:37 <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.
17:47:24 <jallan> new definitions are more operationally defined.
17:49:08 <jallan> issue: editorial--review document for normalization of terms that match new definition
17:49:08 <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 .
17:49:53 <jallan> scribe: jallan
17:50:29 <jallan> SH: some of the definitions overlap
17:51:07 <jallan> ... different kinds of focus, how you get to it or use it. and that cursor, pointer, and caret are different things.
17:51:35 <jallan> GL: these are a hierarchy, but not written that way yet.
17:52:36 <jallan> SH: the pointers are defined by their interaction type. instead of conflating focuses and cursor, discuss each separately.
17:52:56 <jallan> SH: really suggesting grouping.
17:53:06 <jallan> KP: is this a good direction?
17:54:08 <jallan> JS: good to use similar terms, and normalize definitions.
17:54:48 <jallan> KP: need to group and put in hierarchy. Keyboard focus was in the document but not defined.
17:55:02 <jeanne2> +1
17:55:29 <kford> I think the proposal is fine.
17:56:08 <jallan> all present agree with dropping the definition.
17:56:36 <jallan> ... GL wants to pass it by the entire group. add to a survey for next week.
17:58:52 <jallan> ... 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. 
17:58:56 <jeanne2> rrsagent, make minutes
17:58:56 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jeanne2
17:59:06 <jallan> topic: 3.10 implementions
17:59:16 <jallan> scribe: greg
17:59:53 <Kim> Kim has joined #ua
17:59:56 <jallan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0089.html
18:00:12 <jallan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0088.html
18:00:43 <greg> MH: Questioned whether Back button is an accessibility issue.
18:01:33 <greg> JA: Back button important for users with cognitive impairments, and usability issue particularly important for people for whom navigating within the page is difficult.
18:02:13 <greg> General agreement to keep 3.6 (Back button).
18:02:47 <greg> JA: It was 9.4 in UAAG 1.0, discussed in Techniques.
18:06:11 <greg> 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.
18:06:45 <greg> Correction, 3.10.7 through 3.10.12 from Kelly.
18:07:21 <mhakkinen> correction 3.10.1 through 3.10.5 from Mark
18:08:08 <greg> JA: While an SC required allowing font size differences to be preserved during zoom, but nothing required zoom.
18:09:28 <jallan> action: jallan to write sc for allow user to scale text and images
18:09:28 <trackbot> Created ACTION-312 - Write sc for allow user to scale text and images [on Jim Allan - due 2010-03-05].
18:10:11 <kford> /me I am back.
18:13:06 <greg> JA: 3.6.4 (Maintain contrast) is nice but doubts any UA will implement it.
18:13:30 <greg> Greg: Could be relatively easily implemented as an add-in.
18:14:25 <greg> GL: the user can accomplish nearly the same thing by turning off all author-specified colors, but that's the "big hammer" approach.
18:14:56 <greg> KF: More of a wish-list item.
18:14:59 <greg> MH: Definitely doable.
18:15:38 <greg> JA: Nice but seems low on the priority list.
18:16:15 <greg> JS: Contrast is the largest issue for users with vision difficulties related to albinism; it would be a big benefit to them.
18:18:05 <greg> General agreement to remove it, as good but not compelling.
18:18:23 <greg> Resolution: remove 3.6.4 (Maintain Contrast)
18:18:44 <jeanne2> action: jeanne to remove SC 3.6.4 (Maintain Contrast) from draft. 
18:18:44 <trackbot> Created ACTION-313 - Remove SC 3.6.4 (Maintain Contrast) from draft.  [on Jeanne Spellman - due 2010-03-05].
18:20:24 <jallan> topic: Conformance
18:20:47 <greg> JA: The remainder of his items posted to the list.
18:20:57 <jeanne2> http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100226.html#conformance
18:22:15 <greg> GL: Noted that we have not yet addressed the issue that Conformance Requirements don't allow exceptions for inapplicability.
18:23:13 <jallan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0077.html
18:23:41 <jeanne2> action: jeanne to draft a section of Conformance dealing with Not Applicable.  See the email from Greg 2010JanMar/0077.html
18:23:41 <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].
18:24:56 <greg> 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.
18:27:52 <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..." 
18:29:28 <greg> 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.
18:29:42 <greg> Correction: That was JA.
18:30:56 <jallan> UAAG10 has implementation reports (closest thing to conformance claim) http://www.w3.org/WAI/UA/impl-pr2/
18:31:36 <greg> SH: Not in favor of making it optional, but would be OK to have it included in product documents.
18:32:46 <greg> GL: Current wording requires a URI for the claim, so it must be on the Web, not be just in the product documentation.
18:33:32 <greg> SH: Concerned by requirement to list supported technologies (as Kelly expressed yesterday).
18:34:46 <jallan> 3 categories. included - UA supports in accessible way; excluded - ua supports in inaccessible way, and not supported - UA does not support at all.
18:35:14 <jallan> SH: could a UA claim conformance but exclude HTML
18:36:20 <jallan> GL: if a UA supports something, then you must include or exclude it 
18:37:30 <jallan> JS: canvas, UA XYZ, does not support canvas accessibly.
18:38:31 <jallan> JA: canvas is part of html5, if a UA supports HTML5, can a claim exclude a specific element (canvas), seems a slippery slope.
18:40:02 <jallan> GL: guideline 1 says must implement full features of published standards
18:40:43 <jallan> KF: can't blanket statement 
18:40:59 <jallan> UA supports all 4.01, no UA does
18:41:36 <jallan> SH: UA could claim conformance for 4.01, but exclude HTML5? 
18:42:49 <jallan> JS: propose item 5 & 6 of conformance (included & excluded technologies) be removed.
18:43:51 <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. 
18:43:55 <greg> 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.
18:47:10 <jallan> JA: can include/exclude technology. but UA would say 'fail SC xxx, because yyy element is not accessible'
18:47:24 <jallan> ... this is different from excluding an element. don't want to go there.
18:48:00 <Zakim> -sharper
18:48:26 <jallan> GL: discusses major and minor features of a UA, the major parts should be accessible
18:48:48 <jallan> GL: conformance is a can of worms
18:48:53 <jallan> +1 all around
18:50:06 <jallan> KP: can claim conformance by stating a collection of technologies.
18:50:17 <jallan> JS: yes, item 4 
18:51:09 <jallan> GL: surely the UA does not have to file a separate conformance claim for each extension...
18:52:02 <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.
18:52:02 <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].
18:52:04 <jallan> JS: no, just file one claim and list all technologies included
18:52:25 <jallan> MH: what if there are conflicting conformance claims.
18:52:52 <jallan> KF: don't see as an issue. more important as to who is making the claim. 
18:55:13 <jeanne2> rrsagent, make minutes
18:55:13 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jeanne2
18:56:13 <jallan> ... style sheets, claim conformance, what should I say. UA XYZ supports style sheet because, user can choose two different sheets.
18:56:44 <jallan> JA: conformance claim vs implementation report. need testing tools, etc.
18:57:40 <Zakim> -kford
18:57:42 <Zakim> - +1.512.406.aaaa
18:57:43 <Zakim> WAI_UAWG(F2F)9:30AM has ended
18:57:44 <Zakim> Attendees were +1.512.406.aaaa, sharper, kford
18:57:52 <jallan> rrsagent, make minutes
18:57:52 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jallan
19:51:48 <Zakim> Zakim has left #ua
19:56:24 <greg> greg has joined #ua
19:57:05 <jeanne2> http://www.headstar.com/eablive/?p=397
20:00:00 <jallan> jallan has joined #ua
20:11:27 <jallan> scribe: jallan
20:11:43 <Kim> Kim has joined #ua
20:11:45 <jallan> scribe: greg
20:12:12 <greg> Discussion of whether/how we should pursue HTML5 issues.
20:12:50 <greg> MH: If we comments on or raises concerns about HTML5 Video, should he do it as a member of UAWG or as an individual?
20:22:09 <greg> topic: principle 5
20:23:11 <kford> Zakim: Sorry, can someone paste the link to the doc again?
20:24:32 <jeanne2> http://www.w3.org/WAI/UA/2010/ED-UAAG20-20100226/MasterUAAG20100226.html
20:41:04 <kford> Here is some text for 5.3.5 and 5.3.x.  Anyone care to comment?
20:41:40 <kford> Here is some text for 5.3.5 and 5.3.x.  Anyone care to comment?
20:42:16 <kford> 5.3.5 Context Sensitive Help: There is context-sensitive help on all user agent features that benefit accessibility. (Level AAA)
20:42:18 <kford> Intent:
20:42:19 <kford> The purpose of this criteria is to help maximize the discovery of user agent features that benefit accessibility.
20:42:21 <kford> Example:
20:42:23 <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.
20:42:24 <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. 
20:42:26 <kford> Intent:
20:42:27 <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.
20:42:29 <kford> Example:
20:42:30 <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.
20:44:39 <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)
20:44:39 <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? 
20:44:39 <jeanne2> Intent:
20:44:39 <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.  
20:44:42 <jeanne2> Example: 
20:44:44 <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.  
20:44:48 <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)
20:44:50 <jallan> #  Intent of Success Criterion 5.3.3
20:44:52 <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.
20:44:53 <jallan> # Examples of Success Criterion 5.3.3
20:44:55 <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. 
20:44:56 <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?
20:44:58 <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)
20:45:00 <jallan> #  Intent of Success Criterion 5.3.4
20:45:02 <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...
20:45:07 <jallan> ...would make it easier for user to become more functional more quickly with the user agent.
20:45:09 <jallan> # Examples of Success Criterion 5.3.4
20:45:11 <jallan> A specific section in the documentation (local or online) detailing accessibility features of the user agent. 
20:45:13 <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? 
20:45:37 <mhakkinen> 5.3.1 Accessible Format: At least one version of the documentation is either (Level A): 
20:45:37 <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, 
20:45:37 <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). 
20:45:37 <mhakkinen> Intent of Success Criterion 5.3.1: 
20:45:38 <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. 
20:45:43 <mhakkinen> Examples of Success Criterion 5.3.1 
20:45:45 <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. 
20:45:48 <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. 
20:52:36 <Kim> 5.1.1 Option to Ignore
20:52:38 <Kim> Intent of Success Criterion 5.1.1:
20:52:40 <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.
20:52:41 <Kim> Examples of Success Criterion 5.1.1:
20:52:43 <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.
20:56:31 <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) 
20:56:31 <mhakkinen> Intent of Success Criterion 5.3.2: 
20:56:31 <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. 
20:56:34 <mhakkinen> Examples of Success Criterion 5.3.2: 
20:56:36 <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. 
21:06:37 <greg> Suggested rewrite of 5.4.1:
21:06:39 <greg> 5.4.1 The user has a global option to disable recognized mechanisms used by web pages to specify default focus.
21:06:40 <greg> (@@ 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?)
21:06:42 <greg>     * Intent of Success Criterion 5.4.x:
21:06:43 <greg>       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.
21:06:45 <greg>     * Examples of Success Criterion 5.4.x:
21:06:46 <greg>           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.
21:06:49 <greg>           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.
21:06:53 <greg>     * Related Resources for Success Criterion 5.4.x:
21:06:55 <greg>           o NA
21:07:35 <greg> Ignore that, it included all the deleted text. Trying again:
21:07:37 <greg> Suggested rewrite of 5.4.1:
21:07:38 <greg> 5.4.1 The user has a global option to disable recognized mechanisms used by web pages to specify default focus.
21:07:40 <greg> (@@ 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?)
21:07:42 <greg>     * Intent of Success Criterion 5.4.x:
21:07:43 <greg>       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.
21:07:45 <greg>     * Examples of Success Criterion 5.4.x:
21:07:46 <greg>           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.
21:07:49 <greg>           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:
21:07:54 <greg>           o NA
21:08:05 <greg> Minor edit of 5.4.2 plus new intent and examples:
21:08:06 <greg> 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.
21:08:08 <greg>     * Intent of Success Criterion 5.4.x:
21:08:10 <greg>        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
21:08:11 <greg> 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. 
21:08:13 <greg>     * Examples of Success Criterion 5.4.x:
21:08:14 <greg>           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.
21:08:16 <greg> 	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.  ...
21:08:21 <greg> ...        
21:08:23 <greg> 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. 
21:08:26 <greg> * Related Resources for Success Criterion 5.4.x:
21:08:28 <greg>           o UAAG 2.0 3.10.8 Don't Move Focus
21:12:33 <greg> Everyone sent rewrites to the list.
21:12:42 <greg> Topic: Principle 1
21:12:57 <greg> JS would like to work on Implementing details for Principle 1.
21:13:44 <greg> 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.
21:13:45 <jallan> specifically 1.4.1 Follow Specifications: Render content according to the technology specification. This includes any accessibility features of the technology.
21:15:39 <greg> 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.
21:18:50 <greg> Discussion of whether any other standards have such broad requirements for standards compliance.
21:20:56 <jallan> JS: what if " render content according to features implemented by the user agent"
21:22:19 <greg> JS: Could we not require complete implementation of a spec, but the portions implemented be accessible?
21:22:58 <greg> GL: Might a UA then leave out some portions of HTML or CSS that are important for accessibility, and still comply?
21:24:45 <greg> JS reviews origin of this principle in UAAG 1.0.
21:26:57 <jallan> KF & GL: but a UA could implement all of HTMLx and not implement the accessibility bits. that is too big of an out
21:27:02 <greg> GL: 1.1.1 requires compliance with "Level A" requirements in standards, but are there any such?
21:27:35 <jeanne2> rrsagent, make minutes
21:27:35 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jeanne2
21:28:32 <jeanne2> present- 1.512.406.aaaa
21:29:21 <jeanne2> present+ Jim_Allan, Greg_Lowney, Jeanne_Spellman, Kim_Patch, Mark_Hakkinen
21:29:56 <jeanne2> regrets: Patrick_Lauke
21:30:03 <jeanne2> rrsagent, make minutes
21:30:03 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jeanne2
21:30:17 <greg> GL: 1.1.1 seems to require compliance with platform accessibility standards like MSAA, but that is already required by 2.1.1.
21:32:20 <jeanne2> present- +1.512.406.aaaa, kford, sharper
21:32:28 <jeanne2> present+ Kelly_Ford
21:32:33 <jeanne2> rrsagent, make minutes
21:32:33 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jeanne2
21:33:17 <jallan> GL: where your UI is not based on html, etc comply with accessibility standards
21:33:41 <jallan> where your UI is based on html, etc comply with WCAG
21:36:42 <jallan> 1.4 is tough, but if a UA is going to support htmlx it should implement the accessibility bit properly
21:38:30 <jallan> GL drop 1.1, it is redundant to 2.1.1.
21:39:48 <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
21:41:02 <jallan> KF: +1
21:44:26 <greg> Suggest rewording 1.2.x to say something like "User agent user interfaces that are implemented using Web standard technologies conform to WCAG Level..."
21:45:10 <greg> JS: +1
21:45:15 <greg> KP: +1
21:45:21 <jallan> +1
21:46:45 <jallan> Proposed: delete GL 1.1 as it is redundant to 2.1
21:47:51 <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
21:48:45 <jallan> GL: then should say Rendering. "User agent user interfaces that are rendered using Web standard technologies conform to WCAG Level..."
21:49:01 <jallan> MH: is rendered sufficient?
21:50:09 <jallan> discussion of rendered vs implemented. we care about how it is rendered, not actually what the backend is.
21:52:06 <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)
21:52:06 <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].
21:52:20 <jeanne2> action: JS to add proposals for Principle 5 to document. 5.3.3 to 5.4.x
21:52:20 <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].
21:55:15 <greg> 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....
21:55:31 <jallan> which is 2.1
21:56:00 <greg> GL: But, that demonstrates that it is NOT entirely redundant to 2.1, which only deals with platform standards for communicating with assistive technology.
21:56:50 <greg> GL: 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.
21:57:11 <greg> GL: Therefore any UA running on Windows should comply with that convention.
21:57:39 <greg> GL: But that should not be limited to UA whose UI is not implemented using W3 standards.
21:58:22 <greg> GL: 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."
21:58:34 <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. 
21:59:19 <greg> GL: In ISO these are covered under a separate set of success criteria that only apply to "stand-alone systems".
22:00:08 <jeanne2> rrsagent, make minutes
22:00:08 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jeanne2
22:05:16 <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. 
22:07:05 <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. 
22:14:02 <jallan> concept of partial compliance. UA does x, y, z ... will work very well for folks who are blind but not others
22:16:18 <jallan> JA: is that possible use technology exclusion.
22:22:01 <jallan> should have an informal list for how SC match up with specific disbabilities with personas and scenarios for use cases (non-normative)
22:23:01 <jallan> any concerns about specialized browsers not getting conformance.
22:24:52 <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
22:24:52 <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].
22:25:11 <jallan> does the user community want this???
22:25:22 <jallan> if not then we will drop it.
22:27:37 <jallan> what about a mainstream browser tries for partial conformance.
22:28:52 <jallan> want to reward folks for doing things right while pointing out the deficits.
22:29:49 <jallan> rrsagent, draft minutes
22:29:49 <RRSAgent> I have made the request to generate http://www.w3.org/2010/02/26-ua-minutes.html jallan
23:03:37 <kford_> kford_ has joined #ua