W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2011

Re: WCAG 2 on expanding form controls

From: <fischer@dias.de>
Date: Fri, 26 Aug 2011 19:49:53 +0200
Message-ID: <20110826194953.16163ejfynme0wxt@webmail.dias.de>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:34:08 UTC