- From: Jim Allan <allanj@tsbvi.edu>
- Date: Tue, 5 Jun 2012 15:48:01 -0500
- To: WAI-ua <w3c-wai-ua@w3.org>
from http://www.w3.org/2012/06/05-ua-minutes.html - DRAFT - User Agent Accessibility Guidelines Working Group Teleconference 05 Jun 2012 See also: IRC log Attendees Present jim, jan, kelly, greg, kim, jeanne Regrets simon, wayne Chair kellyford, jimallan Scribe jallan Contents Topics GL 2.4 find 2.5.3 provide structural navigation GL 2.6 event handlers 2.6.1 access to event handlers 2..4.5 find in non-visible content 2.5.5 Principle 3 discussion of Action-611, need for new SC addressing spell checking discussion of removing editors note in 3.3.4 about UA extensions and centralized view of the UA principle 4 2.1.5 keyboard trap examples 2.8.1 tool bars Spell Checking reword of 5.3.2 whole word spell check Summary of Action Items <trackbot> Date: 05 June 2012 <kford> Apologies for the late start Jan. http://www.marcozehe.de/2012/05/08/first-round-of-accessibility-support-for-android-in-mobile-firefox/ <jeanne> we are starting now <scribe> scribe: jallan GL 2.4 find basic find with text alternatives find direction case sensitivity (AA) may 31 <Jan> ATAG wording: http://www.w3.org/TR/2012/WD-ATAG20-20120410/#sc_a351 <Jan> A.3.5.1 Text Search: <Jan> If the authoring tool provides an editing-view of text-based content, then the editing-view enables text search, such that all of the following are true: (Level AA) <Jan> (a) All Editable Text: Any text content that is editable by the editing-view is searchable (including alternative content); and <Jan> (b) Match: Matching results can be made visible to authors and given focus; and <Jan> (c) No Match: Authors are informed when no results are found; and <Jan> (d) Two-way: The search can be made forwards or backwards. gl: basic search should be A ... split in to two SC A and AA ... A basic, bidirectional, highlight found item, alert on wrap ... AA etc jr: what is the a11y case for case sensitive search gl: efficiency. see the example in IER 2.5.3 provide structural navigation kf: there are action items associated with this <jeanne> 2.5.6 Navigate by structural element: The user agent provides at least the following types of structural navigation, where the structure types exist:(Level AA) (a) by header (b)within tables gl: the example in 2.5.3 is good. it is structural navigation of the database. kf: does someone understand this enough (2.5.3, 2.5.5.2.5.6 2.5.7) to try to write them gl: this section needs work. kp: 2.5.6 and 2.5.7 seem to cover what is needed. the other 2 are confusing ... what is the overlap. 2.5.3 and 2.5.5 seem prescriptive. gl: 2.5.3 could be rewritten to better reflect the example. ... 2.5.5 is two things. I am on an item jump me to the containing heading. the other part is the breadcrumbs of the structure. ... not sure why they are combined. not clear from the wording if this information is presented to the user directly. kp: is there an overlap gl: 2.5.5 is all about the info on a page. 2.5.3 is all about a database structure. something like a play list and different ways of structuring information. gl: I put my focus on something that is too small, I want to make it bigger. first I have to know what this element is. I open firebug to drill down jr: that's the first part. ... labels could be further away in the hierarchy but still associated. js: how is this different from 1.10.1 gl: let's delete first part of 2.5.5 and keep 1.10.1 ... 2.5.6 is navigation. +1 all kill first half of 2.5.5 user can access explicitly defined relationships jr: fold content hierarchy in 2.5.5 into 2.5.3 gl: no it belongs in principle 1 kf: greg and jr to thrash out 2.5.3 and 2.5.5 and principle location GL 2.6 event handlers kf: don't know of any UA that does this. js: it should not be A. kf: the intent is good. need to reword the SC - jeanne ja: rewrite 2.8.1 to include show/hide close action-504 <trackbot> ACTION-504 Rewrite Background Image Toggle (2.11.1) ier for next week closed <kford> Action-716 Believe existing 219 covers this. <kford> Close Action-716 <trackbot> ACTION-716 Will write a sentence for 2.1.4 Intent and/or example of author supplied UI. closed <Admin> 2.6.1 Access to input methods: <Admin> The user can discover input methods explicitly associated with the keyboard focus element, and be able to activate the element using a modality independent method. (Level A) <Admin> 2.6.1 Access to input methods: <Admin> The user can discover input methods explicitly associated with an element, and be able to activate the element using a modality independent method. (Level AA) <kford> 2.4.5 Find non-rendered alternatives: <kford> Find functionality intended to satisfy UAAG guideline 2.4 offers the ability to search on the following alternatives when they are not visibly rendered but default content for the alternatives offers a visible location to highlight the found result. <kford> A. Alternative text <kford> Examples: <kford> Ronda typically browses the web with images turned off so she sees the alternative text for images rendered in place of images. She visits a favorite web site on a friend's computerand knows she wants to find a link to her favorite rock star's photo gallery. On her computer this is the artist's name so she searches for that word on her friend's computer. The alt text is not dispalyed in... <kford> ...this case but the star's image is highlighted because her find command has associated the alt text with the image. <kford> 2.4.6 CaseSensitive Find <kford> Find functionality intended to satisfy guideline 2.4 offers a case sensitive option for performing searches (level AA) <kford> Intent of Success Criterion 2.4.6 : Searching is much more useful when the user can specify whether case matters in some circumstances. Further this can reduce the number of keystrokes needed to perform a search. <kford> Examples of Success Criterion 2.4.6: <kford> Dennis uses a screen reader. He wants to find all the instances of his friend Bill in a blog post about finances. He needs to specify case in order <kford> to avoid stopping at instances of "bill". Later, he searches for his friend's name in a blog post about poetry where the author never uses capital letters. <kford> In this instance he specifies that case does not matter. <kford> Find functionality intended to satisfy UAAG guideline 2.4 offers the ability to search on the following alternatives when they are present for rendered content. Find functionality offers the ability to search on alternative content when they are not visibly rendered. <kford> 2.4.5 Find non-rendered alternatives: <kford> Find functionality offers the ability to search on alternative content when it is not visibly rendered. <kford> A. Alternative text <kford> B. Captions <kford> Intent: <kford> Authors frequently provide alternative content to meet web content accessibility guidelines. The purpose of this success criteria is to ensure that find functionality allows users to locate this content even if it may not be visible rendered. <kford> Examples: <kford> Ronda typically browses the web with images turned off so she sees the alternative text for images rendered in place of images. She visits a favorite web site on a friend's computer and knows she wants to find a link to her favorite rock star's photo gallery. On her computer this is the artist's name so she searches for that word on her friend's computer. The alt text is not displayed in... <kford> ...this case but the star's image is highlighted because her find command has associated the alt text with the image. <kford> 2.4.6 CaseSensitive Find <kford> Find functionality intended to meet guideline 2.4 offers the ability to perform case sensitive searches. (level AA) <kford> Intent of Success Criterion 2.4.6 : Searching is much more useful when the user can specify whether case matters in some circumstances. Further this can reduce the number of keystrokes needed to perform a search. <kford> Examples of Success Criterion 2.4.6: <kford> Dennis uses a screen reader. He wants to find all the instances of his friend Bill in a blog post about finances. He needs to specify case in order <kford> to avoid stopping at instances of "bill". Later, he searches for his friend's name in a blog post about poetry where the author never uses capital letters. <kford> In this instance he specifies that case does not matter. 2.6.1 access to event handlers <jeanne> 2.6.1 Access to input methods: The user can discover input methods explicitly associated with an element, and be able to activate the element using a modality independent method. (Level AA) access to input methods js: made this broader and more flexible <jeanne> Users interacting with a web browser may be doing so by using one or more input technologies including keyboard, mouse, speech, touch, and gesture. No matter how the user is controlling the user agent, the user needs to know the input methods available to a particular piece of content, and activate that element using an modality independent method. In addition, any one input method should not hold back another. For instance, people who don't use a mouse shouldn't changed level to AA from A kf: why lower priority js: really hard to do. this is what the IndieUI group is about. jr: how much does the user need to know about the method of input., to they really need to know or just get it done. <jeanne> adding to the intent (irc client truncation) For instance, people who don't use a mouse shouldn't have to map their input methods to the same steps a mouse user would take. kp: they need to know. discovery of method makes it easier for the user to decide what to do. gl: this doesn't seem right. ... sc the first and second clause are doing different things first is discovery (non default actions0 second doesn't say that you activate the element which means the default action....not do any secondary actions gl: what is input method vs event handler js: author will associate event handler with an element. user needs to discover input methods associated with the handler, then activate in device independent manner gl: first example in the gl, is it handled by the new sc. ja: want user to have the name of the function that the right click handler will do. gl: need to have recognized input methods ... input method means some element has 2-finger swipe handler, or right click or double click jr: why? gl: go to element, get context menu...one menu item would have menu list of recognized input actions available. jr: if you are going to go somewhere and discover, the user must already know that ... gl: assume using 1.3.1 user will know which items take input then can choose to hover over an element using a menu kp: showing the doors is 1.3.1 gl: what you can do with the door is 2.6.1 jr: so they get a menu with mouse over, mouse off, etc. the user might do something that the developer didn[t anticipate that a mouse user could not do. gl: UA should constrain behaviours, that cannot do a mouse up, if a mouse down has not been executed jr: want to build in these contraints, want to keep the user from doing the wrong thing. kp: issues with this. dragon does not allow using spelling when menus are open. when spell would let you jump to a menu item. really frustrating kf: have a new SC js: don't want to set up something that will conflict with IndieUI develops 2 years <jeanne> Jeremy cannot use a mouse. He needs to activate a flyout menu that normally appears OnMouseOver. Jeremy can navigate to a link on this flyout menu, pull up a context menu listing the available input methods (e.g. click, double-click, swipe left) and activate it using his keyboard. gl: close. but how did he simulate the mouse over from the menu. editing live in the docv <greg> He needs to activate a flyout menu that appears when one hovers the mouse over a button. He navigates to the button and pulls up its context menu, which includes an "Inputs" submenu that lists the available input methods (e.g. click, double-click, swipe left, and hover) and from that he chooses the "Hover" command. gl: note in the intent. UA may want to constrain the available inputs methods based on what is available (e.g. now allowing a mouse up unless a mouse down has been activated) ... programmers make assumptions that they would never expect a keyup without a keydown <jeanne> The user agent can constrain steps such that not allowing a mousedown before a mouseup. kp: still concerns. but ok with it. gl: can be tested with automated testers. kp: ok with JS restatement kf: LOTS of event handlers. this is tough. gl: instead of listing available event handlers, only the handlers that are relevant to the element kf: implement, tab to an element, get a list of relevant handlers and trigger them in sequence only jr: clarify. would you show on mouseDown on every element, or only on registered events available gl: in javascript can you create a generic action watcher without registering the method with the UA <greg> He needs to activate a flyout menu that appears when one hovers the mouse over a button. He navigates to the button and pulls up its context menu, which includes an "Inputs" submenu that lists the available input methods (e.g. events that were registered for this element: click, double-click, swipe left, and hover) and from that he chooses the "Hover" command. resolved: added the above example to 2.6.1 <greg> Users interacting with a web browser may be doing so by using one or more input technologies including keyboard, mouse, speech, touch, and gesture. Sometimes a web page is scripted so that it assumes and requires an input method that's not available to the user, such as a handling drag events when the user relies solely on the keyboard. In those cases, the user needs to determine which input... <greg> ...methods available to a particular piece of content, and activate that element using an modality independent method. In addition, any one input method should not hold back another. For instance, people who don't use a mouse shouldn't <jeanne> Revised Intent: Users interacting with a web browser may be doing so by using one or more input technologies including keyboard, mouse, speech, touch, and gesture. Sometimes a web page is scripted so that it assumes and requires an input method that is not available to the user, such as handling drag events for a user relying solely on the keyboard. In those cases, the user needs to determine what methods are available and activate that element with a modality in <jeanne> In addition, any one input method should not hold back another. For instance, people who don't use a mouse shouldn't have to map their input methods to the same steps a mouse user would take. The user agent can constrain steps such as not allowing a mouseup before a mousedown. resuming meeting <jeanne> 2.6.1 Access to input methods: The user can discover recognized input methods explicitly associated with an element, and be able to activate those methods using a modality independent method. <jeanne> 2.6.1 Access to input methods: The user can discover recognized input methods explicitly associated with an element, and be able to activate those methods using a modality independent manner. <jeanne> 2.6.1 Access to input methods: The user can discover recognized input methods explicitly associated with an element, and activate those methods in a modality independent manner. (Level AA) <kford> 2.4.5 Find non-rendered alternatives: <kford> Find functionality offers the ability to search on alternative content when it is not visibly rendered. <kford> A. Alternative text <kford> B. Captions resolved: the above it inserted into the document <kford> Intent: <kford> Authors frequently provide alternative content to meet web content accessibility guidelines. The purpose of this success criteria is to ensure that find functionality allows users to locate this content even if it may not be visible rendered. <kford> Examples: <kford> Ronda typically browses the web with images turned off so she sees the alternative text for images rendered in place of images. She visits a favorite web site on a friend's computer and knows she wants to find a link to her favorite rock star's photo gallery. On her computer this is the artist's name so she searches for that word on her friend's computer. The alt text is not displayed in... <kford> ...this case but the star's image is highlighted because her find command has associated the alt text with the image. <kford> 2.4.6 CaseSensitive Find <kford> Find functionality intended to meet guideline 2.4 offers the ability to perform case sensitive searches. (level AA) <kford> Intent of Success Criterion 2.4.6 : Searching is much more useful when the user can specify whether case matters in some circumstances. Further this can reduce the number of keystrokes needed to perform a search. <kford> Examples of Success Criterion 2.4.6: <kford> Dennis uses a screen reader. He wants to find all the instances of his friend Bill in a blog post about finances. He needs to specify case in order <kford> to avoid stopping at instances of "bill". Later, he searches for his friend's name in a blog post about poetry where the author never uses capital letters. <kford> In this instance he specifies that case does not matter. <jeanne> the previous resolved is for 2.6.1, not 2.4.5 2..4.5 find in non-visible content kf: split 2.4.5 into 2 new sc. 2.4.5 and 2.4.6 gl: in the sc say EVEN when something is not rendered 2.4.5 Find non-rendered alternatives: Find functionality offers the ability to search on alternative content even when it is not visibly rendered. gl: what about the A and B (alt, captions) can search on captions if they are reveals. kf: to I have to download the whole move to search for captions. discussion of methods of captioning and searching kf: do we need a generic SC with examples, or include a list in the SC. jr: if something is not available to the UA (captions) they it can't do anything with it. js: restricting to 'alt' and available captions should be list ... restricting to alternative text with covers ... alt now and whatever in the future <kford> The user can search for alternative content even when it is not visibly rendered. The user can search alternative content even when it is not visibly rendered. The user can search alternative text and captions even when it is not visibly rendered. The user can search alternative content even when they are not visibly rendered. <kford> The user can search alternative content even when it is not visibly rendered. gl: we lost the bit about "that is available to the user agent" <Jan> alternative content: Content that can be used in place of default content that may not be universally accessible. Alternative content fulfills the same purpose as the original content. Examples include text alternatives for non-text content, captions for audio, audio descriptions for video, sign language for audio, media alternatives for time-based media. See WCAG for more information. The user can search alternative content even when it is not visibly rendered that is available to the user agent. The user can search alternative content that is available to the user agent even when it is not visibly rendered. resolved: 2.4.5 The user can search alternative content (including captions) that is available to the user agent even when it is not visibly rendered. <kford> Authors frequently provide alternative content to meet web content accessibility guidelines. The purpose of this success criteria is to ensure that find functionality allows users to locate this content even if it may not be visible rendered. <kford> Examples: <kford> Ronda typically browses the web with images turned off so she sees the alternative text for images rendered in place of images. She visits a favorite web site on a friend's computer and knows she wants to find a link to her favorite rock star's photo gallery. On her computer this is the artist's name so she searches for that word on her friend's computer. The alt text is not displayed in... <kford> ...this case but the star's image is highlighted because her find command has associated the alt text with the image. gl: doesn't say why this is important to pwd kf: yes it does. <greg> It only restates the SC. js: it is helpful for users with disabilities to search on this content that is not visible kp: +1 example ja: +1 example <Jan> jr +1 resolved: 2.4.5 is done above <kford> 2.4.6 CaseSensitive Find <kford> Find functionality intended to meet guideline 2.4 offers the ability to perform case sensitive searches. (level AA) <kford> Intent of Success Criterion 2.4.6 : Searching is much more useful when the user can specify whether case matters in some circumstances. Further this can reduce the number of keystrokes needed to perform a search. <kford> Examples of Success Criterion 2.4.6: <kford> Dennis uses a screen reader. He wants to find all the instances of his friend Bill in a blog post about finances. He needs to specify case in order <kford> to avoid stopping at instances of "bill". Later, he searches for his friend's name in a blog post about poetry where the author never uses capital letters. <kford> In this instance he specifies that case does not matter. gl: we have not used this phrasing in the SC before jr: more useful than case sensitivity is whole word. ... should be one generic SC to include all these bits about searching ... accessibility case is efficiency kf: then we need to revise one more time. 2.5.5 <Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0101.html EXISTING: 2.5.5 Access to Relationships which Aid Navigation: The user can access explicitly-defined relationships based on the user's position in content, and the path of nodes leading from the root of any content hierarchy to that position. (Level AA) PROPOSAL: -some of the SC is covered, by 1.10.1. The rest will be covered by a new SC: 1.10.2 Access to Element Hierarchy: The user can determine the path of element nodes from the root element of the element hierarchy to the currently focused or selected element. (Level AA) Intent: Users who have difficulty working with a web page or document can use user style sheets or scripts to modify its presentation or interaction to better meet their needs. This often requires them to identify specific elements, their attributes, and their position in the element hierarchy. The user agent can facilitate this process by allowing the user to navigate to an element, or select it if... scribe: it is not navigable, and querying the information they need. If this features is not provided, the user may not be able to find the corresponding element in the source view or entire document tree. Examples: Jack wants certain content on a web page to be displayed in a larger font, and wants to create a user style sheet that would modify its appearance. He needs to identify the class or ID of the particular element, so he puts the focus onto or selects the text he's interested in, opens the browser's debug window, which shows him that the selected text is an element with class "story" inside a... scribe: paragraph inside a DIV with class "Premiere". He then knows the combination of classes and element types to specify in the user style sheet. discussion of 2.5.3 with itunes example of playlist with songs, artist, album genre, etc with implied relationships kp, ja, kf: +1 gl: simon should have a say, since he wrote the original resolved: delete 2.5.5 and add new 1.10.2 as written above greg will write clear description then we will share with simon and discuss gl: 1.10.2 still needs a bit of work topic 2.4.3 match found <greg> The remaining issue with 1.10.2 is that a UA could comply with the letter but be entirely useless to the user, by providing a list of elements without their class, ID, or style attributes. Providing those is implied by the Intent and Example, but not required by the SC. Intent for 2.4.3 It is important for the user to easily recognize that a search term has been found and that the term is revealed to the user in context. The user agent moves the viewport to include the found term and the term is highlighted in some fashion. It is assumed that the point of regard is the found element in the viewport, any subsequent searches on the same term or other navigation tasks(e.g.... scribe: tabbing to the next anchor) begin from this point. New searches would begin from the top of the document. @@ Editors' Note: If the caret has been moved, from its new location.@@ remove editor's note, if caret is moved by the user then the point of regard is moved and same search begins from the current point of regard. It is important for the user to easily recognize that a search term has been found and that the term is revealed to the user in context. The user agent moves the viewport to include the found term and the term is highlighted in some fashion. The point of regard is the found element in the viewport. Any subsequent searches on the same term or other navigation tasks (e.g. tabbing to the next... scribe: anchor) begin from this point. resolved: intent for 2.4.3 put into document and editors note deleted close action-671 <trackbot> ACTION-671 Create a test page for seachring "hidden" content and send to the list closed close action-669 <trackbot> ACTION-669 Write definition of 'hidden content' - outside viewport, heighth width 0, same color as background closed resolved: remove definition of Hidden Content in 2.4.5 as it is covered in a different SC Principle 3 discussion of Editors note before 3.1.2 this should be UAAG next, it is a general interface thing, hard to justify as an accessibility item. issue: sc to be created to remove future warning messages in May 31 draft (editors note in 3.1) to be moved to UAAG.next <trackbot> Created ISSUE-94 - Sc to be created to remove future warning messages in May 31 draft (editors note in 3.1) to be moved to UAAG.next ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/94/edit . close action-459 <trackbot> ACTION-459 Add google instant information to the IER for 2.1.2 closed discussion of Action-611, need for new SC addressing spell checking resolved: remove editors note from summary of 3.2 <Jan> http://www.w3.org/TR/2012/WD-ATAG20-20120410/#sc_a421 resolved: editors note in 3.2.2, remove second paragraph of intent. kp and ja like the wording of ATAG, change 3.3.2 to match gl: worried about b: describe in the interface....may be time with the developers say it is described because it is obvious. <greg> e.g. hover over a mysterious check box and the tooltip just repeats the same cryptic label text. discussion of removing editors note in 3.3.4 about UA extensions and centralized view of the UA js: its not possible to embed extension help within the UA kp: in the UA in the help if there are extensions then there is a button that links to where you might find help about the extension gl: extensions are separate products, and centralized view of a11y features are in separate area ... modify intent <jeanne> This is on a per-product basis, nested user agents would have separate centralized documentation. <jeanne> This is on a per-product basis. Nested user agents or addons may provide separate centralized documentation. resolved: modify the intent of 3.3.4 with above Jeanne statement principle 4 <Jan> http://www.w3.org/TR/2012/WD-ATAG20-20120410/#sc_a122 discussion of 4.1.2 and 4.1.6 there is action-651 to combine them ATAG does not specify any of the a11y properties <Jan> A.2.2.2 Access to Rendered Text Properties: If an editing-view renders any text formatting properties that authors can also edit using the editing-view, then the properties can be programmatically determined. 4.2.1 the user can move the keyboard focus to a nested user agent level A gl: this should be covered by the keyboard SC This is important for testing. gl: combine with 4.2.2 to keep the concept or add as an example for the keyboard SC ... what is difference between 4.2.2 and 4.2.3 one is user and one is user agent js: 2.1.5 covers 4.2.1 and 4.2.2 ja: so they are redundant gl: but if I get into something without the keyboard it does not say I have to get out of the item with the keyboard. kp: mixing and matching is important ... combine intents and examples between all. jr: they really overlap alot. kp: aria example in 4.2.2 is good an should be kept. gl: can remove all of 4.2 and subsume all uner 2.1.5 jr: do we need a note about nested user agents in 2.1.5 resolved: delete all 4.2 and reword 2.1.5 and move relevant examples close action-610 all incorporated into 2.1.5 <jeanne> 2.1.5 No Keyboard Trap (former 2.1.3): If keyboard focus can be moved to a component using a keyboard interface (including nested user agents), then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, users are advised of the method for moving focus away. (Level A) need to write examples for 2.1.5 <Jan> This might be a nice replacement for 5.3.2 (http://www.w3.org/TR/2012/WD-ATAG20-20120410/#sc_a121) 2.1.5 keyboard trap examples <Admin> - Ari has repetitive strain injuries that are exacerbated when he uses the mouse. He is using a video hosting site where each page hosts a <Admin> nested media player. He presses Tab until the focus in on the media player, then presses Enter to activate and put the keyboard focus <Admin> on it. When he's finished watching the video, he presses Tab to navigate to the comments below the video, but cannot get the focus to <Admin> leave the video player. He presses Alt+Left to return to the previous page, but that also fails because the video player is consuming <Admin> those keystrokes. Luckily, Ari knows that Shift+Esc will return focus from a nested user agent, with or without its cooperation. Thus, <Admin> even a badly behaved nested user agent cannot prevent Ari from getting on with his work. <Admin> - Jay has repetitive strain injuries that are exacerbated when he uses the mouse. He moves the focus to a toolbar extension that does not <Admin> relinquish control back to the user agent. Jay presses Alt-D to move the focus to the address bar. <Admin> - Mary is a blind user who does not use the mouse. She moves the focus to an embedded scripted application that was poorly <Admin> programmed. She presses a documented key combination -- Alt+N -- to override the scripting and move the focus to the next element <Admin> in the content. <Admin> - Katan does not use the mouse and has trouble with short-term memory. He is using a virtual machine. The escape sequence is Shift+Ctrl+Escape. Every time Katan opens the program, it briefly shows the escape sequence near the top right corner of the screen. The VM also has an Exit option in its menu system. The Escape keystrokes are also indicated on the menu. <Admin> - Ari has repetitive strain injuries that are exacerbated when he uses the mouse. He is using a video hosting site where each page hosts a nested media player. He presses Tab until the focus in on the media player, then presses Enter to activate and put the keyboard focus on it. When he's finished watching the video, he presses Tab to navigate to the comments below the video, but cannot get... <Admin> ...the focus to leave the video player. He presses Alt+Left to return to the previous page, but that also fails because the video player is consuming those keystrokes. Luckily, Ari knows that Shift+Esc will return focus from a nested user agent, with or without its cooperation. Thus, even a badly behaved nested user agent cannot prevent Ari from getting on with his work. <Admin> - Jay has repetitive strain injuries that are exacerbated when he uses the mouse. He moves the focus to a toolbar extension that does not relinquish control back to the user agent. Jay presses Alt-D to move the focus to the address bar. <Admin> - Mary is a blind user who does not use the mouse. She moves the focus to an embedded scripted application that was poorly programmed. She presses a documented key combination -- Alt+N -- to override the scripting and move the focus to the next element in the content. <Admin> - Katan does not use the mouse and has trouble with short-term memory. He is using a virtual machine. The escape sequence is Shift+Ctrl+Escape. Every time Katan opens the program, it briefly shows the escape sequence near the top right corner of the screen. The VM also has an Exit option in its menu system. The Escape keystrokes are also indicated on the menu. gl: on Ari, how do I get the focus to leave the video player. its not clear about what you are trying to achieve. ... what is the expected behavior that the UA is repairing resolved: add the above examples into 2.1.5 2.8.1 tool bars <greg> Existing: <greg> 2.8.1 Configure Position: The user can add, remove, and reorder any toolbars and similar containers, and the items within them. (Level AA) <greg> 2.8.2 Restore Default Toolbars: The user can restore the default toolbar, panel, or inspector configuration. (Level AAA) <greg> Proposed: <greg> 2.8.1 Configure Toolbars: The user can add, remove, reorder, show, and hide any toolbars and similar containers, and the items within them. (Level AA) <greg> 2.8.2 Reset Toolbar Configuration: The user can restore all toolbars and similar containers to their default configuration. (Level AAA) <greg> Glossary entry for Toolbars and similar containers: <greg> A collection of commonly used controls presented in a region that can be configured or navigated separately from other regions. Such containers may be docked or free-floating, permanent or transient, integral to the application or add-ons. Variations are often called toolbars, palettes, panels, or inspectors. gl: did not review the IER of 2.8.1 and 2.8.2 jr: +1 to sc +1 close action-514 <trackbot> ACTION-514 Write glossary definion for toolbar closed jr: what would not be a toolbar in a UA gl: status bar, history sidebar, etc, could expand list ... if a standard windows app you can't move the menu bar. <greg> A collection of commonly used controls presented in a region that can be configured or navigated separately from other regions. Such containers may be docked or free-floating, permanent or transient, integral to the application or add-ons. Variations are often called toolbars, palettes, panels, inspectors, sidebars, or status bars. <greg> As Jan points out, menu bars would fit in the definition; Greg points out that in standard Windows-based applications one cannot move the menu bar. <greg> But it's AA so OK. <greg> A collection of commonly used controls presented in a region that can be configured or navigated separately from other regions. Such containers may be docked or free-floating, permanent or transient, integral to the application or add-ons. Variations are often called toolbars, palettes, panels, inspectors, sidebars, status bars, and menus. resolved: add 2.8.1 and 2.8.2 and glossary add editors <kford> 3.2.x Provide spell checking functionality <kford> User agents provide spell checking functionality for text created inside the user agent (level AA). <kford> Intent: <kford> Users with various disabilities benefit from the features found in spell checkers today when composing text. It is commonplace to create significant amounts of content inside a user agent today for tasks such as email, social networking and web-based productivity applications such as word processors. The intent of this success criteria is to ensure that users with disabilities can easily... <kford> ...correct spelling errors when compsoing text. <kford> Example: <kford> Amanda is dyslecix and frequently spells words incorrectly. She is able to correct words when alerted to the errors. She navigates to her web-based email application and composes a new message. The user agent alerts her to spelling errors as she is typing and she quickly corrects the mistakes and sends an error free message. <scribe> ACTION: greg to review definition of toolbar as it may include having the entire UI be configurable including menus, status bars, etc [recorded in http://www.w3.org/2012/06/05-ua-minutes.html#action01] <trackbot> Created ACTION-735 - Review definition of toolbar as it may include having the entire UI be configurable including menus, status bars, etc [on Greg Lowney - due 2012-06-12]. Spell Checking <kford> 3.2.x Provide spell checking functionality <kford> User agents provide spell checking functionality for text created inside the user agent (level AA). <kford> Intent: <kford> Users with various disabilities benefit from the features found in spell checkers today when composing text. It is commonplace to create significant amounts of content inside a user agent today for tasks such as email, social networking and web-based productivity applications such as word processors. The intent of this success criteria is to ensure that users with disabilities can easily... <kford> ...correct spelling errors when composing text. <kford> Example: <kford> Amanda is dyslexic and frequently spells words incorrectly. She is able to correct words when alerted to the errors. She navigates to her web-based email application and composes a new message. The user agent alerts her to spelling errors as she is typing and she quickly corrects the mistakes and sends an error free message. gl: 'text created' make it text entered jr: entered in UA text areas <kford> 3.2.x Provide spell checking functionality <kford> User agents provide spell checking functionality for text entered inside the user agent by a user. (level AA). <kford> Intent: <kford> Users with various disabilities benefit from the features found in spell checkers today when composing text. It is commonplace to create significant amounts of content inside a user agent today for tasks such as email, social networking and web-based productivity applications such as word processors. The intent of this success criteria is to ensure that users with disabilities can easily... <kford> ...correct spelling errors when composing text. <kford> Example: <kford> Amanda is dyslexic and frequently spells words incorrectly. She is able to correct words when alerted to the errors. She navigates to her web-based email application and composes a new message. The user agent alerts her to spelling errors as she is typing and she quickly corrects the mistakes and sends an error free message. <greg> User agents provide spell checking functionality for text users enter in the user agent. (level AA). <kford> Intent: <kford> Users with various disabilities benefit from the features found in spell checkers when composing text. It is commonplace to create enter significant amounts of content inside a user agent for tasks such as email, social networking and web-based productivity applications such as word processors. The intent of this success criteria is to ensure that users with disabilities can easily correct... <kford> ...spelling errors when composing text. <greg> How about adding to the Intent: "...particularly users with dyslexia and other disabilities that significantly increase their chance of misspelling words. <greg> "This is particularly important for..." Users with various disabilities, benefit from the features found in spell checkers when composing text. This is particularly important for users with dyslexia and other disabilities that significantly increase their chance of misspelling words. It is commonplace to enter significant amounts of content inside a user agent for tasks such as email, social networking and web-based productivity... scribe: applications such as word processors. The intent of this success criteria is to ensure that users with disabilities can easily correct .spelling errors when composing text. <greg> I'd change "The user agent alerts her to spelling errors as she is typing and she quickly corrects the mistakes and sends an error free message." to "The user agent alerts her to spelling errors as she is typing so she can quickly correct the mistakes and sends an error free message." Amanda is dyslexic and frequently spells words incorrectly. She is able to correct words when alerted to the errors. She navigates to her web-based email application and composes a new message. The user agent alerts her to spelling errors as she is typing and she quickly corrects the mistakes and sends an error free message. resolved: new 3.2.x spell check <Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0103.html reword of 5.3.2 Suggest moving to the wording of ATAG 2.0 (http://www.w3.org/TR/2012/WD-IMPLEMENTING-ATAG20-20120410/#sc_a121) Accessibility Guidelines: If the user agent contains non-web-based user interfaces, then those non-web-based user interfaces follow user interface accessibility guidelines for the platform. (Level A) Intent: The intent of this success criterion is to ensure that user agent user interfaces that are not web applications are more accessible to authors with disabilities. Existing platform accessibility guidelines are referenced because accessibility guidelines already exist for many platforms and this wording allows developers the flexibility to conform with accessibility legislation in their markets. Note: Developers should see the documents listed in the "Related Resources for Success Criterion A.1.2.1" section. Unless special circumstances exist (e.g., a document has been superseded, the platform has undergone major architectural changes), the listed resources should be assumed to be relevant to the platforms listed. Examples: Mobile browser: The developer of a browser app for the iPhone platform follows the guidance provided in the "Accessibility Programming Guide for iPhone OS". Related Resources for Success Criterion A.1.2.1: The following is a non-exhaustive list of accessibility guidelines for various platforms: Desktop OS GNOME Desktop on Linux: GNOME Accessibility Developers Guide KDE Desktop on Linux: Developer's Information Mac OS: Accessibility Overview Microsoft Windows: Accessibility Overview Mobile OS Android: Android Developers: Designing for Accessibility BlackBerry: BlackBerry Accessibility iPhone OS: Accessibility Programming Guide for iPhone OS Cross-OS environments Eclipse: Designing Accessible Plug-ins in Eclipse Java SE: Java SE Desktop Accessibility Lotus Notes: Lotus Notes Checklist The following is a non-exhaustive list of general software accessibility guidelines: ISO 9241-171:2008 Ergonomics of human-system interaction - Part 171: Guidance on software accessibility Software Checklist (IBM) Section 508 §1194.21 Software applications and operating systems The WAI International Policies Relating to Web Accessibility resource includes links to various international legislation and other policies that may include applicable accessibility guidelines for non-web-based functionality. jr: this replace the old 5.3.2 ... how do you meet this, review platform a11y specs. ... now just grab the right documents/specs and follow them gl: we had a definition of accessibility features. jr: old 5.3.2 was hard for developers to do. <Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0104.html whole word spell check <scribe> ACTION: jan review new wording on 5.3.2 at the next meeting [recorded in http://www.w3.org/2012/06/05-ua-minutes.html#action02] <trackbot> Created ACTION-736 - Review new wording on 5.3.2 at the next meeting [on Jan Richards - due 2012-06-12]. <scribe> ACTION: jim to present 3.3.2 to list and bring up at next meeting [recorded in http://www.w3.org/2012/06/05-ua-minutes.html#action03] <trackbot> Created ACTION-737 - Present 3.3.2 to list and bring up at next meeting [on Jim Allan - due 2012-06-12]. jr: replace find with Text search ... then need change stems in several sc. resolved: replace find with 'text search' in the document jan's proposals" (1) For all of the SCs in 2.4, change "Find" to "Text Search" (2) Splitting out searching alternates (building on what was discussed earlier): 2.4.5 Search in alternative content: The user can perform text searches within textual alternative content (e.g. *text alternatives for non-text content*, captions) even when the textual alternative content is not rendered onscreen. Intent: Authors frequently provide alternative content to meet web content accessibility guidelines, which users with disabilities will experience as part of the content. The purpose of this success criteria is to ensure that find functionality allows users to locate this content, even if it may not be visible rendered. Examples: - Ronda typically browses the web with images turned off so she sees the alternative text for images rendered in place of images. She visits a favorite web site on a friend's computer and knows she wants to find a link to her favorite artist's photo gallery. On her computer this is the artist's name so she searches for that word on her friend's computer. The alt text is not displayed in this... scribe: case but the artist's image is highlighted because her find command has associated the alt text with the image. (3) 2.4.X Text Search (Enhanced): The user can specify that a text search will be: (a) case-sensitive; and (b) whole word only. Intent: Many users make use of text search to reduce the number of keystrokes required to reach a known location within web content. The number of unintended search results can be reduced by allowing the user to specify that capitalization of the search term and whether the term is a whole word. Examples: - Dennis uses a screen reader. He wants to find all the instances of his friend Bill in a blog post about finances. He needs to specify case and that the search term is a "whole word" in order to avoid stopping at instances of "bill" or "Billing ...". Later, he searches for his friend's name in a blog post about poetry where the author never uses capital letters. In this instance he... scribe: specifies that case does not matter. gl: comment, alternative content phrase is really long. ... comment, alternative content phrase is really long. all vote yes resolved: put 2.4.5 above in the document <greg> To meet web content accessibility guidelines, authors frequently provide alternative content which users with disabilities will experience as part of the content. Summary of Action Items [NEW] ACTION: greg to review definition of toolbar as it may include having the entire UI be configurable including menus, status bars, etc [recorded in http://www.w3.org/2012/06/05-ua-minutes.html#action01] [NEW] ACTION: jan review new wording on 5.3.2 at the next meeting [recorded in http://www.w3.org/2012/06/05-ua-minutes.html#action02] [NEW] ACTION: jim to present 3.3.2 to list and bring up at next meeting [recorded in http://www.w3.org/2012/06/05-ua-minutes.html#action03] [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 Tuesday, 5 June 2012 20:48:31 UTC