- From: <fischer@dias.de>
- Date: Fri, 26 Aug 2011 19:49:53 +0200
- To: w3c-wai-gl@w3.org
DF: I completely agree that the example we were discussing (changing, on input, the number of items in a shopping cart above the focus position) does not constitute a change of context so SC 3.2.2 "On Input" is indeed not the right relation for such a failure. If the focus is moved through the updating (or not restored to the triggering position) it would seem to fall under 2.4.3 Focus order. Quoting James Nurthen <james.nurthen@oracle.com>: > sorry about the typo below - I meant 3.2.2 not 3.3.2! > > On 8/26/2011 9:29 AM, James Nurthen wrote: >> 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 17:50:16 UTC