- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 6 Mar 2014 13:34:54 -0600
- To: WAI-ua <w3c-wai-ua@w3.org>
- Message-ID: <CA+=z1Wmg5my1GZNntnpL8xD5b=RW3Zu_5MwfFgZ32-Wkmpg=wg@mail.gmail.com>
from: http://www.w3.org/2014/03/06-ua-minutes.html User Agent Accessibility Guidelines Working Group Teleconference 06 Mar 2014 See also: IRC log http://www.w3.org/2014/03/06-ua-irc <http://www.w3.org/2014/03/06-ua-irc> Attendees PresentJim_Allan, Greg_Lowney, Jan, Kim_Patch, KellyRegretsjeanneChairJimAllan, KellyFordScribeallanj Contents - Topics <http://www.w3.org/2014/03/06-ua-minutes.html#agenda> 1. OP06 "important elements"<http://www.w3.org/2014/03/06-ua-minutes.html#item01> 2. MS03 1.4.1 Separation between browsers and OS<http://www.w3.org/2014/03/06-ua-minutes.html#item02> - Summary of Action Items<http://www.w3.org/2014/03/06-ua-minutes.html#ActionSummary> ------------------------------ <trackbot> Date: 06 March 2014 http://www.w3.org/WAI/UA/2014/LCcomments.html OP06 "important elements" <scribe> scribe: allanj Guideline 2.3 "important elements" Since important elements have been left at the discretion of the user (and will vary from user to user, and from web page to web page) ... It will be quite the task for the user agent to determine from the user which elements he/she thinks is important and have the proper facilities to navigate directly to it. Can make the criteria of 'important elements'... scribe: more objective or easily definable? jr: we meant to leave it to the UA developer as to the definition of "important elements" gl: Glossary: important elements are up to the UA <Greg> Definition of important elements <Greg> Elements determined as important by the user to facilitate the user's navigation of the content. UAAG 2.0 intentionally does not identify which important elements must be navigable because this will vary by user needs and technologies being used. <Greg> 2.5.3 Allow Elements to be Configured for Structural Navigation: The user can configure a set of important elements (including element type) for structured navigation and hierarchical/outline view. (Level AAA) <Jan> important elements: Elements determined as important for users by the user agent to facilitate the user's navigation of the content. UAAG 2.0 intentionally does not identify which important elements must be navigable because this will vary by user needs and technologies being used. <Greg> The definition says the user defines the set of important elements, but the SC saying the ability to define set is only AAA. gl: 2.3.1 navigate to important elements (AA), but not defined by user (2.5.3 AAA) <Jan> important elements: Elements determined as important for users by the user agent to facilitate the user's navigation of the content. UAAG 2.0 intentionally does not identify which important elements must be navigable because this will vary depending on the web technology. gl: html does not define 'important elements' <Jan> important elements: Elements determined as important for users by the user agent to facilitate the user's navigation of the content. UAAG 2.0 intentionally does not identify which important elements must be navigable because this will vary depending on the user agent design and the web technology. <Greg> Editorial rewrite of Jan's: "Elements that the user agent identifies as important for facilitating the user's navigation of the content." <kford> Rewrite is good to me. <Jan> important elements: Elements that the user agent identifies as important for facilitating the user's navigation of the content. UAAG 2.0 intentionally does not identify which important elements must be navigable because this will vary depending on the user agent design and the web technology. ja: 2.5.3 allows user to choose any element jr: no...choose from the important element list provided by the UA ja: thats not clear in the SC gl: could add to the intent ... to comply with 2.3.1 the UA provides the user the ability to navigate by at least one element (h1) ja: suggest removing 2.5.3 because no one will do it. gl: hopes mouseless browsing would add heading nav in addition to link navigation. jr: wonders if with heading and table navigation (2.5.2) and enabled elements (2.3.3) thinks we have important elements covered. ... perhaps can eliminate 2.3.1 (it is so basic, UA could provide 1 choice) and 2.5.3 kp: OK with removing 2.3.1. gl: 1.9.1 outline view of important elements. jr: allowing users to choose which elements could get difficult for the UA kp: want to keep 2.5.3. jr: what is the work 2.5.3 is doing. ... want something in the notes for 1.9.1 that outline views are more usable when they are configurable. gl: 2.3.1 is redundant to 2.3.3 and 2.5.2 ... what else might 2.3.1 used for... what elements? jr: 2.3.3 is navigate to and activate - separate actions for enabled elements ... 2.5.2 is nav by headings and tables, 1.9.1 is outline view of important elements kf: this is a bit confusing. ... end goal direct nav and activate enabled elements kp: need to nav to and nav + activate in one step kf: want default behavior of whatever UA does. kp: the user doesn't know what the UA will do when something gets focus. ... mouseless browsing is nav+activate kf: tabbing gives focus with out activation. <scribe> *ACTION:* Jan with create a proposal for 1.9.1, 2.3.1, 2.3.3, 2.5.2, 2.5.3 with definition for 'important elements" [recorded in http://www.w3.org/2014/03/06-ua-minutes.html#action01] <trackbot> Created ACTION-956 - With create a proposal for 1.9.1, 2.3.1, 2.3.3, 2.5.2, 2.5.3 with definition for 'important elements" [on Jan Richards - due 2014-03-13]. gl: Word is a UA that allow granular navigation move forward 3 graphics, or up 2 sections, etc. so it is possible to do this type of navigation close item 1 open item 2 2.3.2 Present Direct Commands from Rendered Content: The user can have any recognized direct commands in rendered content (e.g. accesskey, landmark) be presented with their associated elements (e.g. Alt+R to reply to a web email). (Level AA) comment: based on intent of 2.3.2 However, if we are to have proper documentation of the accessibility functionality (Guideline 3.3) then, presumably, there it will be made discoverable. Users will just need to go through the documentation to discover all relevant controls. ja: this is a misunderstanding, we are talking about Rendered content, not UI content The UA can not have documentation for Author supplied Direct Commands (accesskey) <scribe> *ACTION:* Jeanne to add response to OP07 - his is a misunderstanding, we are talking about Rendered content, not UI content. The UA can not have documentation for Author supplied Direct Commands (accesskey) [amith as necessary] [recorded in http://www.w3.org/2014/03/06-ua-minutes.html#action02] <trackbot> Created ACTION-957 - Add response to op07 - his is a misunderstanding, we are talking about rendered content, not ui content. the ua can not have documentation for author supplied direct commands (accesskey) [amith as necessary] [on Jeanne F Spellman - due 2014-03-13]. MS03 1.4.1 Separation between browsers and OS comment: While it is understood that the separation between browsers features and OS features can be blurry at times, there are functions that are generally expected to be provided by the OS to facilitate accessibility. We do not expect the working group to delineate the responsibility of OS and browsers since it is contextual and fluid. But we expect the working group to recognize such... ... separation of responsibility. For example, success criterion 1.4.1 (Text Scale, Color, Font) should be separated into two criteria--one simply asking the browsers to follow the OS text size and such at level A and another to provide its own options if the OS fails to provide text options at level AA. <Greg> The general statement is too vague to be actionable. That is, I don't expect any disagreement on the sentiment, but rather on the details. I disagree with this example provided: if a browser does not provide adjustable font sizes, it is neither fully accessible nor as accessible as users have come to expect. If the operating system does not provide the features in any standardized way, it is... <Greg> ...up to each application to provide them on its own, and if the feature is useful and common enough to be expected, whether it is provided in a consistent way or not is less important. jr: aren't you agreeing with them. current situation. mobile allow setting text size and color, most UAs allow font size change ... but, don't agree with creating 2 SCs gl: UA allow following OS font and colors, or let user do their own. ... this should still be level A. <Greg> That is, if a feature such as customizable colors is important (which it is), the browser can be expected to provide it at Level A regardless of whether or not it's implement at the OS level. ja: all browsers already do this. it is up to the UA to decide to do it on its own or use the OS <Greg> The feature should not be relegated to Level AA just because the OS did not provide a standardized implementation. <Greg> If there are specific success criteria that you feel should be split into separate levels for when the OS supports it and when it doesn't, please enumerate these and we will try to address your concerns. <Greg> Do we have both "follow OS colors" and "allow user to the override them"? <Jan> 5.1.3 Implement Accessibility Features of the Platform: <Jan> If the user agent contains non-web-based user interfaces, then those user interfaces follow user interface accessibility guidelines for the platform. (Level A) <Jan> Note: When a requirement of another specification contradicts a requirement of UAAG 2.0, the user agent may disregard the rendering requirement of the other specification and still satisfy this guideline. ja: font size and color is an accessibility setting jr: thats where you find it on android OS Applicability note: if the OS provides the features the UA does not need to duplicate as long as the features trickle through <KimPatch> Suggested edit: <KimPatch> Applicability note: if the OS provides a feature the UA does not need to duplicate it as long as user agent supports the OS feature <Greg> We could have an SC that explicitly said something like "For the following presentation attributes, the user can choose which of the following take precedence (a) user global settings specified by the platform, or (b) author-specified settings, or (c) user-specified settings. * Foreground and background colors..." <Greg> That is reflecting the features already in desktop browsers (e.g. Firefox). jr: on mobile, platform does foreground/background (inverse color), the applications cannot over ride ... windows phone has high contrast mode, ie for mobile will use HCM ... windows could add a user setting to ignore HCM in the UA, but expect they would say turn off HCM. ... applicability notes are the loopholes and SC are the you musts Applicability note: if the OS provides a feature the UA does not need to duplicate it as long as user agent supports the OS feature gl: conformance claim you list the OS, UA, and extensions...that's not clear enough jr: but MS make comment that its not clear, hence applicability note gl: feature needs to be available regardless of the location of the feature OS, UA, or extension and are enumerated in the conformance claim ... mean to say platform (many layers within the platform) <Greg> A required behavior can be provided by the platform, user agent, extensions, and potentially other layers. All are acceptable, as long as they are enumerated in the conformance claim. <Greg> The user agent does not need to implement every behavior itself. A required behavior may be provided by the platform, user agent, user agent extensions, or potentially other layers. All are acceptable, as long as they are enumerated in the conformance claim. <Jan> GL's wording works for me. any objections to adding this as #6 in conformance applicability notes +1 kp: +1 gl: +1 kelly: ? <scribe> *ACTION:* jeanne to add "6. The user agent does not need to implement every behavior itself. A required behavior may be provided by the platform, user agent, user agent extensions, or potentially other layers. All are acceptable, as long as they are enumerated in the conformance claim." to applicability notes. [recorded in http://www.w3.org/2014/03/06-ua-minutes.html#action03] <trackbot> Created ACTION-958 - Add "6. the user agent does not need to implement every behavior itself. a required behavior may be provided by the platform, user agent, user agent extensions, or potentially other layers. all are acceptable, as long as they are enumerated in the conformance claim." to applicability notes. [on Jeanne F Spellman - due 2014-03-13]. <scribe> *ACTION:* jeanne add to disposition document - that we added "6. The user agent does not need to implement every behavior itself. A required behavior may be provided by the platform, user agent, user agent extensions, or potentially other layers. All are acceptable, as long as they are enumerated in the conformance claim." to document as a response to comment MS03 [recorded in http://www.w3.org/2014/03/06-ua-minutes.html#action04] <trackbot> Created ACTION-959 - Add to disposition document - that we added "6. the user agent does not need to implement every behavior itself. a required behavior may be provided by the platform, user agent, user agent extensions, or potentially other layers. all are acceptable, as long as they are enumerated in the conformance claim." to document as a response to comment ms03 [on Jeanne F Spellman - due 2014-03-13]. Summary of Action Items *[NEW]* *ACTION:* Jan with create a proposal for 1.9.1, 2.3.1, 2.3.3, 2.5.2, 2.5.3 with definition for 'important elements" [recorded in http://www.w3.org/2014/03/06-ua-minutes.html#action01] *[NEW]* *ACTION:* jeanne add to disposition document - that we added "6. The user agent does not need to implement every behavior itself. A required behavior may be provided by the platform, user agent, user agent extensions, or potentially other layers. All are acceptable, as long as they are enumerated in the conformance claim." to document as a response to comment MS03 [recorded in http://www.w3.org/2014/03/06-ua-minutes.html#action04] *[NEW]* *ACTION:* jeanne to add "6. The user agent does not need to implement every behavior itself. A required behavior may be provided by the platform, user agent, user agent extensions, or potentially other layers. All are acceptable, as long as they are enumerated in the conformance claim." to applicability notes. [recorded in http://www.w3.org/2014/03/06-ua-minutes.html#action03] *[NEW]* *ACTION:* Jeanne to add response to OP07 - his is a misunderstanding, we are talking about Rendered content, not UI content. The UA can not have documentation for Author supplied Direct Commands (accesskey) [amith as necessary] [recorded in http://www.w3.org/2014/03/06-ua-minutes.html#action02] [End of minutes] -- Jim Allan, Accessibility Coordinator & Webmaster Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Thursday, 6 March 2014 19:35:23 UTC