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.


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