WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible table filtering options

for

From: Allison Bloodworth
Date: Nov 5, 2010 10:24AM

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