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.......