- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 20 Feb 2014 13:38:28 -0600
- To: WAI-ua <w3c-wai-ua@w3.org>
- Message-ID: <CA+=z1WnuF9qpBww_6fBxibUeicxyoT-rbUcJex5SjX+JaHUPmw@mail.gmail.com>
from: http://www.w3.org/2014/02/20-ua-minutes.html User Agent Accessibility Guidelines Working Group Teleconference 20 Feb 2014 See also: IRC log http://www.w3.org/2014/02/20-ua-irc <http://www.w3.org/2014/02/20-ua-irc> Attendees PresentJim_Allan, Greg_Lowney, Kim_Patch, Jan, Jeanne, KellyRegretsericChairJimAllan, KellyFordScribeallanj Contents - Topics <http://www.w3.org/2014/02/20-ua-minutes.html#agenda> 1. IER for Reflow SC<http://www.w3.org/2014/02/20-ua-minutes.html#item01> 2. IER 1.8.y <http://www.w3.org/2014/02/20-ua-minutes.html#item02> 3. 1.8.z <http://www.w3.org/2014/02/20-ua-minutes.html#item03> 4. SB06:Which is also related to WD2<http://www.w3.org/2014/02/20-ua-minutes.html#item04> 5. MS01 web-based user agent<http://www.w3.org/2014/02/20-ua-minutes.html#item05> 6. MS01 separation UA from AT<http://www.w3.org/2014/02/20-ua-minutes.html#item06> - Summary of Action Items<http://www.w3.org/2014/02/20-ua-minutes.html#ActionSummary> ------------------------------ <trackbot> Date: 20 February 2014 ls IER for Reflow SC http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0038.html <scribe> scribe: allanj jr: reviews IERs <Jan> When content is reflowed to stay on the screen such that horizontal scrolling is not necessary, she can read and understand it. <Jan> REMOVE When text is reflowed so it is in one column that doesn't require horizontal scrolling or vertical scrolling to get to another column, she can read and understand it. gl: intent of 1.8.y last sentence - default reflow?? <Jan> Since most user agents default to reflowing content within the horizontal dimensions of the top-level viewport, this success criteria gives users the option to check whether the user agent's default horizontal reflow might be sufficient for them. <Jan> Since most user agents default to reflowing content within the horizontal dimensions of the top-level viewport, this success criteria gives users the option to check whether the default reflow (i.e. with author specified absolute layout dimensions overridden) might be sufficient for them. Resolution: IER for 1.8.x accepted IER 1.8.y <Jan> Most user agents default to wrapping content within the horizontal dimensions of the top-level viewport unless authors specify absolute layout dimensions that necessitate extending the content beyond the width of the viewport. This success criteria gives users the option to check whether the user agent's default content wrapping might be sufficient for them. <Jan> Most user agents default to wrapping content within the horizontal dimensions of the top-level viewport unless authors specify absolute layout dimensions that necessitate extending the content beyond the width of the viewport. This success criteria gives users the option to check how the content would appear without those author-specified absolute layout dimensions. Intent of Success Criterion 1.8.Y: --- Content is not as easily usable if the user has to scroll back and forth horizontally. This is an especially acute issue for users who find it difficult or impossible to use the mouse to scroll and for users who find it difficult to reorient when the content changes. Most user agents default to wrapping content within the horizontal dimensions of the top-level viewport unless authors... scribe: specify absolute layout dimensions that necessitate extending the content beyond the width of the viewport. This success criteria gives users the option to check how the content would appear without those author-specified absolute layout dimensions. gl: technical issues. absolute values are used to prevent horizontal scrolling. single line edit box with initial content ... the width might be set to the width of the content, and wouldn't expand jr: sounds like making this to complicated ... you can imagine lots of other cases, this is the general case gl: we have another SC related to window dimensions? jr: don't think we have one like that ... things will fall apart on any device when zooming in or screen size reach certain points. Resolution: IER for 1.8.Y with Intent above in minutes is accepted. <Jan> and single column reflow features 1.8.z <Jan> REMOVE This is especially useful for scientific papers and newsletters that are in that are multiple columns. gl: re: Notes on these SC, make it clear that user can turn on/off the feature <Greg> "Note: Some layouts may become unusable if author-specified layout is overridden. In this case, the user can turn linearization off and try another strategy. It is recommended that user agents provide a convenient way for the user to turn this behavior on and off." <Greg> That would be for both notes. Resolution: add "It is recommended that user agents provide a convenient way for the user to turn this behavior on and off." to Notes for 1.8.X and 1.8.Z <Jan> 1.8.Y Content is not as easily usable if the user has to scroll back and forth horizontally. This is an especially acute issue for users who find it difficult or impossible to use the mouse to scroll and for users who find it difficult to reorient when the content changes. Most user agents default to wrapping content within the horizontal dimensions of the top-level viewport unless authors... <Jan> ...specify absolute layout dimensions that necessitate extending the content beyond the width of the viewport. This success criteria gives users the option to check how the content would appear without those author-specified absolute layout dimensions. <KimPatch> Edits for clarity, example 1.8.x <KimPatch> - Frank has repetitive strain injuries and uses speech input. When Frank uses his mobile phone to read a web page, he needs to zoom in to read an article on a web site. He configures his mobile phone so that text reflows to always display zoomed content to fit in one column. <KimPatch> Edits for clarity, example for 1.8.z <KimPatch> - Ansgard has low vision and physical disabilities that make it difficult to use the mouse. He needs to zoom in to read text. When using his PDF viewer, he makes use of the zoom and single column reflow features to reflow the content into a single column that fits the window. Resolution: accept Kim edits of examples above ... IER for 1.8.Z accepted rrsagent: make minutes <Jan> "Note: Some layouts may become unusable if author-specified layout is overridden. In this case, the user can turn linearization off and try another strategy. It is recommended that user agents provide a convenient way for the user to turn this behavior on and off." <KimPatch> 1.8.X edit of stem for consistency, other stems good <KimPatch> Allow Multi-Column Text Reflow close action-947 <trackbot> Closed action-947. <Jan> http://www.w3.org/WAI/UA/2014/LCcomments.html <Jan> JA: SB01: Done <Jan> JA: SB02: Done <Jan> JA: SB03: Done <Jan> JR: SB02 may need some more detail... SB02 - New SC and IERs added http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0038.html <Jan> JA: SB04: OK <Jan> JA: SB05: Essentially done...needs example update. <Jan> JA: SB06: .... <Jan> JA: SB06:Which is also related to WD2 SB06:Which is also related to WD2 1.4.3 Text Spacing and Style (Globally): The user can globally set all of the following characteristics of visually rendered blocks of text:(Level AA) SB06: 1.4.3 and 1.4.6 BOTH mention "line spacing" - does it really need to be listed twice? With different settings ranges? or maybe I've misunderstood (which means others might misunderstand). <Jan> https://www.w3.org/2002/09/wbs/36791/20131016/results#xq6 MS01 web-based user agent UAWG have discussed this extensively. js: UAAG does not supersede WCAG, we augment as accessibility relates to the UA UI jr: should move reference to WCAG closer to the top of the document js: moved reference to WCAG to the Implementing document, perhaps should bring it back http://www.w3.org/TR/2013/WD-IMPLEMENTING-UAAG20-20131107/#intro-wcag <Jan> JR: Should go back into GL move ATAG reference also no objections <scribe> *ACTION:* move the Relationship to WCAG from implementing to guidelines, move Role of UA in Web Authoring from Implementing to guidelines [recorded in http://www.w3.org/2014/02/20-ua-minutes.html#action01] <trackbot> Error finding 'move'. You can review and register nicknames at < http://www.w3.org/WAI/UA/tracker/users>. <scribe> *ACTION:* Jeanne move the Relationship to WCAG from implementing to guidelines, move Role of UA in Web Authoring from Implementing to guidelines [recorded in http://www.w3.org/2014/02/20-ua-minutes.html#action02] <trackbot> Created ACTION-949 - Move the relationship to wcag from implementing to guidelines, move role of ua in web authoring from implementing to guidelines [on Jeanne F Spellman - due 2014-02-27]. <Greg> For MS01: <Greg> "It may not be obvious to the user whether something is web-based or native, so we see no substantial reason why one category be entirely exempt. Rather, there should be exemptions from specific success criteria where one category would encounter technical limitations. We trust the commenter would agree that authoring tools accessibility guidelines would apply to all authoring tools, whether... <Greg> ...they are platform-specific or web-based, so the argument that web apps should only adhere to WCAG is already discounted. <Greg> "On the other hand, it may make sense to have a subset of the guidelines that more narrowly targets web browsers, as opposed to applications that merely use web standard document formats, etc. It is possible to create targeted documents that call out only a subset of the guidelines and success criteria, or filter them based on the feature set of a particular product, without needing to... <Greg> ...change the main guidelines document." <Jan> +1 UAWG has added 2 new sections to the Guidelines document to reflect our thinking on UAAG relationship to WCAG and ATAG <Greg> "As the commenter suggests, it may make sense to have a subset of the guidelines that more narrowly targets web browsers, as opposed to applications that merely use web standard document formats, etc. It is possible to create targeted documents that call out only a subset of the guidelines and success criteria, or filter them based on the feature set of a particular product, without needing... <Greg> ...to change the main guidelines document." <Greg> "As the commenter suggests, it may make sense to have a subset of the guidelines that more narrowly target web browsers, as opposed to applications that merely use web standard document formats, etc. It is possible to create targeted documents that call out only a subset of the guidelines and success criteria, or filter them based on the feature set of a particular product, without needing... <Greg> ...to change the main guidelines document. perhaps add on: UAWG has added 2 new sections to the Guidelines document to reflect our thinking on UAAG relationship to WCAG and ATAG <Greg> "UAWG has added 2 new sections to the Guidelines document to clarify the UAAG relationship to WCAG and ATAG." +1 Resolution: Response to MS01: It may not be obvious to the user whether something is web-based or native, so we see no substantial reason why one category be entirely exempt. Rather, there should be exemptions from specific success criteria where one category would encounter technical limitations. We trust the commenter would agree that authoring tools accessibility guidelines would apply to... ... all authoring tools, whether they are platform-specific or web-based, so the argument that web apps should only adhere to WCAG is already discounted. As the commenter suggests, it may make sense to have a subset of the guidelines that more narrowly target web browsers, as opposed to applications that merely use web standard document formats, etc. It is possible to create targeted documents that call out only a subset of the guidelines and success criteria, or filter them based on the feature set of a particular product, without needing to... scribe: change the main guidelines document. UAWG has added 2 new sections to the Guidelines document to clarify the UAAG relationship to WCAG and ATAG. MS01 separation UA from AT <Greg> Proposed response: <Greg> "Providing guidelines for software that does synthesized speech does not equate with targeting AT, which as you've noted is already explicitly exempted. For example, early versions of the Kindle provided text to speech that was not targeting people with disabilities; if browsers provide speech output for mainstream users, they should be making the speech configurarable enough to be usable by... <Greg> ...a wide range of individuals." When an extension add speech output to the UA it becomes part of the UA and should meet the requirements of 1.6 ja: Seems that 1.6 is very specific to text to speech. would be ok with removing the GL js: all of the SC have the clause "if synthesized speech is produced". think we should keep it. ... there are auditory browsers and extension that are very useful to large groups of people with disabilites. ... it is not separate AT. Proposed Resolution - Providing guidelines for software that does synthesized speech does not equate with targeting AT, which as you've noted is already explicitly exempted. For example, early versions of the Kindle provided text to speech that was not targeting people with disabilities; if browsers provide speech output for mainstream users, they should be making the speech configurarable... scribe: enough to be usable by a wide range of individuals. When an extension adds speech output to the UA, it becomes part of the UA and should meet the requirements of 1.6 Clarified 1.6.3 to apply only to UAs that provide synthesized speech Resolution: Providing guidelines for software that does synthesized speech does not equate with targeting AT, which as you've noted is already explicitly exempted. For example, early versions of the Kindle provided text to speech that was not targeting people with disabilities; if browsers provide speech output for mainstream users, they should be making the speech configurable enough to be usable by a... scribe: wide range of individuals. When an extension adds speech output to the UA, it becomes part of the UA, and, should meet the requirements of 1.6. UAWG clarified 1.6.3 to apply only to UAs that provide synthesized speech. Summary of Action Items *[NEW]* *ACTION:* Jeanne move the Relationship to WCAG from implementing to guidelines, move Role of UA in Web Authoring from Implementing to guidelines [recorded in http://www.w3.org/2014/02/20-ua-minutes.html#action02] *[NEW]* *ACTION:* move the Relationship to WCAG from implementing to guidelines, move Role of UA in Web Authoring from Implementing to guidelines [recorded in http://www.w3.org/2014/02/20-ua-minutes.html#action01] [End of minutes] -- Jim Allan, Accessibility Coordinator & Webmaster Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964
Received on Thursday, 20 February 2014 19:38:57 UTC