- From: James Nurthen <james.nurthen@oracle.com>
- Date: Fri, 26 Aug 2011 09:29:48 -0700
- To: Detlev Fischer <fischer@dias.de>
- Cc: w3c-wai-gl@w3.org
comments inline preceded by JN: On Aug 25, 2011, at 11:32 PM, Detlev Fischer wrote: > Regarding the suggested failure, > > "FXXX: Failure of 3.2.2, (and Failure of 3.1.1) due to making changes without notification to a page (in the reading order) before the control that caused the change." > > I agree with James Nurthen that there are cases in which it makes sense to update the information above the focus position without informing the user. The crucial point is whether the same information will reappear at its due point in the process. For example, at the checkout of an online shop, information about the number of items will be restated before the user commits to purchase. JN: On re-reading 3.3.2 the important thing is whether the change is a "change of context" or not. This failure only applies to changes which are changes of context. If we are going to create a failure technique it needs to be tightly worded such that it doesn't prohibit anything which is not a change of context. > > What does that mena for the sufggerseted Failure? I think it is valid in general, the test for it however would need to include a check whether the user must rely on the change above or whether the change is redundant (due to reappear later in the process). > > As mentioned by some before, ARIA live regions may help announcing state changes without moving the current focus but UA / AT saupport for live regions is probably still not sufficient currently to satisfy the SC when used to announce vital informaton (i.e. information that the user must rely upon). JN: While using ARIA to notify about changes which are not changes of context may sometimes be useful, 3.2.2 does not seem to require any notification unless the change is also a change of context. > > Detlev > > Am 25.08.2011 23:29, schrieb Katie Haritos-Shea: >> I think the thing to take into account here is that IF it changes >> the user focus. Having that information that 4 new things are in >> your cart may not be a problem, the problem is if you are moved >> somewhere (focus-wise), that is unknown or not expected. That is the >> crux IMHO. >> >> And David I think has covered this well in this proposal. >> >> Thank you David! >> >> -----Original Message----- >> From: James Nurthen >> Sent: Aug 25, 2011 2:26 PM >> To: w3c-wai-gl@w3.org >> Subject: Re: WCAG 2 on expanding form controls >> >> I'm not sure I agree about >> "FXXX: Failure of 3.2.2, (and Failure of 3.1.1) due to making >> changes without notification to a page (in the reading order) before >> the control that caused the change." >> >> There are many cases when changing something earlier in the page is >> the logical thing to do and should not be a failure even if the user >> is not notified. >> Take, for instance, amazon.com. When I add something to my shopping >> cart the number on the cart updates to show the number of items in >> the cart. This information, while useful, is not a necessary part of >> the process. I'm not sure anyone needs to be notified that this >> update has occurred - indeed - as a sighted user this information is >> often scrolled off the top of the screen and I'm not aware it has >> been updated until I decide I want to go to look at it to see how >> many items I have in my cart. This works exactly the same for a >> screen reader user. >> >> Doing something like this, where the update is "obvious" based on >> the application being used, should not be a failure. >> >> >> On 8/25/2011 11:00 AM, David MacDonald wrote: >> >>> This issue of inserting content into pages is prevalent... I >>> recommend we add something like the four following techniques: >>> >>> SCRXX for 3.2.2, 3.1.1 >>> >>> Inserting or changing the content of a page while keeping (or >>> returning) focus on the initiating control. >>> >>> Gxxxx: Notifying the user of behaviour before a control changes or >>> inserts content into a web page. >>> >>> FXXX: Failure of 3.2.2, (and Failure of 3.1.1) due to not keeping >>> (or returning) the focus on the control that caused the change in >>> page content. >>> >>> FXXX: Failure of 3.2.2, (and Failure of 3.1.1) due to making >>> changes without notification to a page (in the reading order) >>> before the control that caused the change. >>> >>> David MacDonald >>> >>> www.eramp.com <http://www.eramp.com> >>> >>> *From:*w3c-wai-gl-request@w3.org >>> [mailto:w3c-wai-gl-request@w3.org] *On Behalf Of *Katie Haritos-Shea >>> *Sent:* August-17-11 7:48 PM >>> *To:* David MacDonald; 'WCAG' >>> *Cc:* 'Loretta Guarino Reid'; 'Gregg Vanderheiden'; 'Michael Cooper' >>> *Subject:* Re: WCAG 2 on expanding form controls >>> >>> Thanks for providing this David, >>> >>> I am thinking that the explained 'behavior' description should >>> includes the information about where in the >>> reading-order/tab-order the user will be returned to at the end of >>> that form component interaction. >>> >>> Theoretically it should return you back to the logical place you >>> just left before the change of context occurred. If it returns you >>> back to the top/beginning of the page - then that should also be >>> identified, as this is often what happens - and I am unsure just >>> how annoying this is to AT users.......but I know compliance >>> testers find it annoying........and I feel it is disorienting. >>> >>> I am also concerned about the text input that causes changes of >>> context, - being clearly identified as being included as one of >>> the covered form/context behaviors - though G13 seems to allude to >>> that in the second example - maybe we need a clearer identification. >>> >>> In my world this issue is coming up often. >>> >>> Katie >>> >>> -----Original Message----- >>> From: David MacDonald >>> Sent: Aug 17, 2011 6:51 PM >>> To: 'WCAG' >>> Cc: 'Loretta Guarino Reid' , 'Gregg Vanderheiden' , 'Michael >>> Cooper' >>> Subject: WCAG 2 on expanding form controls >>> >>> >>> In preparation for our discussion of expanding forms, I’ve >>> (we’ve) heard from several blind screen reader users. Their >>> comments are below... there may be a few more comments from >>> another user that I’ve contacted. The consensus currently >>> seems to be the following. >>> >>> It’s ok to provide a control on a form (such as a dropdown, or >>> checkbox etc) that makes the form expand to add extra content, >>> (or contract to remove content) provided the following four >>> factors are true: >>> >>> 1.The focus stays on the control when the change happens >>> >>> 2.The page does not reload >>> >>> 3.The changes to the form occurs after the control (in the >>> code order) that causes the changes >>> >>> 4.If the changes to the form include plain text that would not >>> be in the tab order then there should be instructions provided >>> on the control describing the behaviour. This would be >>> provided via the Title element of the control, or WAI ARIA, or >>> another manner which would be obvious to a screen reader user >>> who is tabbing through the controls. >>> >>> We may want to require a description of the behaviour also. >>> >>> Cheers >>> >>> David MacDonald >>> >>> Discussion: >>> >>> A blind man in his 30’s, expert JAWS user says: >>> >>> “I agree with the blind contributor who says that it is fine >>> so long as the content being generated appears after the >>> control. The experience could be further enhanced by putting >>> live-aria on the new content. Adding a title tooltip on the >>> control may be useful in some situations but unnecessary in >>> others. This behaviour on pages doesn't bother me and can make >>> for a better user experience when it actually works well with AT.” >>> >>> A blind man in his 50’s full time employed in IT, uses all >>> popular screen readers, prefers WindowEyes says: >>> >>> “This will present a challenge to text to speech software >>> developers. I do see their value though. >>> >>> It is going to be difficult to have expanded content without >>> refreshing the page. Some sites seem to do this, but I don't >>> know how they achieve it. The web access for Microsoft >>> Exchange does OK and for the most part leaves your text to >>> speech software where it needs to be. Others will put your >>> review cursor to the top. System Access is better at this, >>> because they don't have a forms mode on/off per say. >>> Window-Eyes struggles with it and JFW is better at it, because >>> they are following the System Access idea....I don't know how >>> you would describe such behaviour so that it is intuitive to >>> everyone. I just deal with it the way it is for now. In my >>> mind it is one of those situations where one just has to learn >>> how certain pages function. Although I can see this being a >>> challenge for a busy site where you need to select a product, >>> a model, serial number within a range, then a specific >>> firmware version. But if you are a person using such a site to >>> get a driver or something of that nature, wouldn't you have >>> the experience and knowledge to deal with such pages?” >>> >>> A woman in her 40’s, intermediate JAWS, System Access user says: >>> >>> Hi David, I tend to agree with what the other blind person >>> said. I remember being at a page like that once and I didn't >>> realize what was happening at first so I thought there was a >>> problem with the page and didn't realize. If the page puts you >>> right where you were, so you can read down and find the extra >>> content, it is better. Once I know a site and if it is done >>> properly, I could jump through by headings to see the extra >>> content, that is okay but not as good. Because, if you don't >>> know the site and how it works, it takes longer to find the >>> content you want. I do hate it when the page reloads and I >>> have to find my place again especially if it is a large site >>> with a lot of content. >>> >>> Expert user in his 30’s – JAWS... >>> >>> “I'm on-side re this. I personally don't care if the page >>> reloads, so long as focus returns to the control. But that's >>> me. Will there be any off-screen or other text informing the >>> beginning and end of the expanded text? Also, how will the >>> state (expanded collapsed) be exposed to ATs.” >>> >>> >>> Sailesh, on our list says: >>> >>> “I agree with: Some said as long as the extra content appears >>> after the control that generated it, it s ok. with a rider: >>> The page does not refresh / reload causing loss of focus or >>> the focus is re-positioned to where it should be. Usually if >>> appearance of new form controls is dependent on choice from >>> checkbox / radio/ SELECT and the tab flow is managed >>> logically, it poses no problem. >>> >>> Another scenario is a set of links like a tree menu and when >>> one is expanded a set of child links is presented below it. >>> Here 4.1.2 will also apply: one needs to know it is a >>> menu-link and whether it is expanded /collapsed. Also oned >>> needs to be able to identify the child links as a group... >>> their start and finish. Yet in other cases, it is necessary to >>> notify the user of the behavior. Usually if content (like >>> chart or a data table or other stuff that does not get focus >>> is present below the UI element and this content changes based >>> on the choice made via the UI element, the user should be >>> notified about the behavior. For instance, if data displayed >>> relates to a province or state selected from a drop down and >>> there is no Go button after the drop down. This may be done >>> with page refresh or without.” >>> >>> Jason says: >>> >>> “Based on a quick check, these both seem to be cases in which >>> 4.1.2 is not met. Certainly, it is exactly this kind of >>> problem that 4.1.2 was intended to address, as I recall.” >>> >>> David responds: >>> >>> There may have been the intention in 4.1.2 to require >>> notifications of changes to page content. However, it is not >>> clear to me in reading the understanding doc for 4.1.2 that >>> there is an obligation under WCAG to announce a change to the >>> page to assistive technology, but only to make the change >>> programmatically available. We may need to add language to the >>> 4.1.2 understanding to articulate this. >>> >>> Cheers >>> >>> David MacDonald >>> >>> www.eramp.com <http://www.eramp.com> >>> >>> >>> >>> * katie * >>> >>> Katie Haritos-Shea >>> Section 508 Technical Policy Analyst >>> >>> 703-371-5545 >>> >>> People may forget exactly what it was that you said or did, >>> but they will never forget how you made them feel....... >> >> >> * katie * >> >> Katie Haritos-Shea >> Section 508 Technical Policy Analyst >> >> 703-371-5545 >> >> People may forget exactly what it was that you said or did, >> but they will never forget how you made them feel....... >> > > > -- > --------------------------------------------------------------- > Detlev Fischer PhD > DIAS GmbH - Daten, Informationssysteme und Analysen im Sozialen > Geschäftsführung: Thomas Lilienthal, Michael Zapp > > Telefon: +49-40-43 18 75-25 > Mobile: +49-157 7-170 73 84 > Fax: +49-40-43 18 75-19 > E-Mail: fischer@dias.de > > Anschrift: Schulterblatt 36, D-20357 Hamburg > Amtsgericht Hamburg HRB 58 167 > Geschäftsführer: Thomas Lilienthal, Michael Zapp > --------------------------------------------------------------- >
Received on Friday, 26 August 2011 16:33:06 UTC