WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible table filtering options

for

From: James Nurthen
Date: Nov 5, 2010 11:00AM

I'm not sure this is a case where aria-live should be used. I think the
correct property for this situation is aria-controls
http://www.w3.org/TR/wai-aria/states_and_properties#aria-controls

<http://www.w3.org/TR/wai-aria/states_and_properties#aria-controls>;Regards,
James

On Fri, Nov 5, 2010 at 09:19, Allison Bloodworth
< <EMAIL REMOVED> >wrote:

> Thanks much Nathalie!
>
> I am now leaning toward using the table filtering option as most of the
> users of this page will be frequent users who could learn this interaction
> once and hopefully remember it over time.
>
> However, I'm concerned whether there is an accessibility problem with the
> content of the table changing based on what is entered into the search boxes
> *without* having a button. Apparently that would be fine if the user pressed
> a button--but I'm hoping if they know that typing something in that box
> changes the content (e.g. using instructional text, as Nathalie describes)
> could that be just as good. Could anyone point me to any WCAG or Section 508
> guidelines about how to inform a user when something on the page changes? I
> looked at several documents but couldn't find anything.
>
> Normally I would think the best thing to do would be to bring focus there
> (e.g. if an error message is generated, if you move the user's focus to the
> beginning of it that is the next thing that will be read), but that doesn't
> really make sense when an entire table is changing and there are other
> filters that can be used on the way. The user will get there themselves very
> shortly, anyway, after they move through all the filters.
>
> I was also wondering if it would be best to use ARIA Live Regions, but it's
> my understanding that most screen readers don't support it yet:
> 6.5.2. Live Region Attributes
>
> This section contains attributes specific to live regions in rich internet
> applications. These attributes may be applied to any element. The purpose of
> these attributes is to indicate that content changes may occur without the
> element having focus, and to provide assistive technologies with information
> on how to process those content updates. Some roles specify a default value
> for the aria-live attribute specific to that role. An example of a live
> region is a ticker section that lists updating stock quotes.
>
> aria-atomic
> aria-busy (state)
> aria-live
> aria-relevant
>
> By the way, the reason I wanted to avoid the "Go" button is because I
> wanted to provide one-click access to filters. I still believe "Go" buttons
> are clunky and don't feel very "web-2.0" to users but perhaps a drop-down
> doesn't either. If I didn't use the table filters, I think now that I'd
> probably instead include a list of "quick links" (which would represent what
> was in the drop-down) above the table, something like:
>
> All Cases | My Cases | My Office's Cases | Completed Cases
>
> Cheers,
> Allison
>
> On Nov 5, 2010, at 1:07 AM, Nathalie Sequeira wrote:
>
> > Hello Allison,
> >> 2a. I vote for the "Go" button, as a sighted user. One of my pet
> >> peeves are select lists that change my screen after making a
> >> selection. I often forget the select list still has focus, and when I
> >> attempt to scroll the screen with my mouse wheel to review the
> >> results, the selection list scrolls and the data changes. Really,
> >> REALLY annoying! (Yes, "User error - replace user!" But, there are
> >> over 6 billion people on Earth, and I'm guessing I'm not alone!)
> >>
> > You're not, Terrill - what a wonderful description of my own (sighted)
> > user experience, which I have observed in a good number of other users
> > too :)
> >
> > With respect to the "despised" *go* button (I wouldn't want one for each
> > input - one could perhaps serve for all?) :
> > WCAG 2.0 level A still requires that changes of context (whereby WAI
> > itself questions what that means...something to ponder) should be
> > explicitly user-initiated / warned aforehand:
> > http://www.w3.org/TR/WCAG20/#consistent-behavior-unpredictable-change
> > It may be worthwhile studying that section, which offers different
> > possibilities that may be inspiring in this case?...
> > For example, perhaps providing instructions before the beginning of the
> > form (e.g. indicating that changes to the dataset are made live during
> > selection/input) would make it viable to leave in the non-button
> > interactivity more or less as is (provided labels etc. already pointed
> > out are added)...?
> >
> > As a developer I'd have a bit of an issue with the input title
> > attributes' contents (or is this just in there for demo purposes?): all
> > contain general instructions for use:
> > - which are repetitive
> > - which will not be visible to people using tab navigation
> > - tooltip display is also problematic for people with low vision, since
> > its texts don't enlarge
> > So these instructions are something I'd put in a "usage tips&hints"
> > section/box/page - e.g. similarly to how it is done on the PicNet Filter
> > description page ...
> >
> > Otherwise, a cool filter, yep :)
> >
> > HTH
> > Nathalie
> >
> >
> >