Re: WCAG 2 on expanding form controls

Thanks for the interesting coverage of the expanding-forms pattern.

In the past, there have been reports that inserted content may not 
(always) be exposed to screen readers. A good (but German) coverage 
linking to several test pages can be found in Alexander Farkas' blog, 
protofunc:
http://www.protofunc.com/2009/10/11/der-grose-screenreader-focus-test/

The test pages may be instructive for those wanting to check the 
behaviour with different AT and versions of AT.

In the blog post mentioned, one solution proposed to ensure that 
inserted content is exposed is the use of the setTimeout method, setting 
a very small delay. Another option is dynamically re-writing the content 
of the control that expands content to reflect the status, or re-writing 
its title.

The article is 1 1/2 years old now so the situation may have changed a 
bit in newer versions of screen readers (but remember many users will 
still be using an older setup).

Regarding techniques and failures, the setTimeout script is clearly a 
bug repair strategy so I guess it is not something likely to be 
considered a WCAG technique.

Regards,
Detlev


Am 18.08.2011 03:41, schrieb David MacDonald:
> 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.
>
> This seems to qualify as a change of context under our current
> definition and so 3.2.1, 3.2.2 apply. However, 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.
>
> 5.3.2.2 requires a description of the behaviour also.
>
> I think we could adapt G13 for this purpose and also add an HTML,
> WAI-ARIA technique (and maybe livecycle), (or simply add examples to G13
> in those technologies) Here are some possible new techniques.
>
> 1) For 3.3.2 HTML xxx: Using the Title attribute to describe expanding
> content activated by a form or link element. (or we could introduce
> HTML, and WAI ARIA examples to G13)
>
> (This I think is distinct from H65 (Title element) in that it is not a
> label but rather instructions about behaviour)
>
> 2) Failure of 3.2.2 due to a page refresh on activation of a form control
>
> (this is different than F41)
>
> 3) Failure of 3.2.2 due to automatically removing focus from a control
> that causes the page to expand.
>
> Cheers
>
> David MacDonald
>
> Discussion:
>
> I think the issue is covered in 3.2.1 (On Focus) and 3.2.2 (On Input).
> And there are some techniques that somewhat address it (G13: Describing
> what will happen before a change to a form control that causes a change
> of context to occur is made
> <http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/complete.html#G13>
>
> F41: Failure of Success Criterion 2.2.1, 2.2.4, and 3.2.5 due to using
> meta refresh with a time-out
> <http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/complete.html#F41>
>
> 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 “and
> notification of changes to these items is available to user agents,
> including assistive technologies” So content needs to be
> programmatically available but not necessarily announced. However 3.3.2
> requires instructions, and I think the need for blind users to know that
> there will be expanding text would be covered there.
>
> Cheers
>
> David MacDonald
>
> www.eramp.com <http://www.eramp.com>
>


-- 
---------------------------------------------------------------
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 Thursday, 18 August 2011 07:25:08 UTC