WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible table filtering options

for

From: Hoffman, Allen
Date: Nov 4, 2010 2:03PM

If you open the dropdown boxes with the keyboard command, is that
helpfu. Shouldn't need a go button in that case.



-----Original Message-----
From: Terrill Bennett [mailto: <EMAIL REMOVED> ]
Sent: Thursday, November 04, 2010 7:45 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Accessible table filtering options

I tried the demo using keyboard and NVDA. My humble opinion is...

1. The two check boxes have no associated labels. As I tab through
the form, all NVDA says is "Check box not checked. Check box not
checked." Didn't try JAWS, but JAWS usually searches for something
that might be a label and might get lucky, so we'll wait for that
verdict from someone using JAWS - not that relying on luck is a good
plan.

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

2b. I vote for the "Go" button, as a keyboard user (using a screen
reader, or person with any other disability precluding the use of a
mouse). After tabbing to a select list using the keyboard, the only
way to make a selection sans mouse is to down/up arrow through the
list. *IF* your browser doesn't protect you from triggering the
OnChange event (Firefox does protect me), changes happen every time
you arrow looking for the item of your dreams.

3. No, NVDA did not announce there were changes to the data as I
filtered.

4. The tables don't use SCOPE= or ID= attributes. The table does,
however, use the TH tag for the headings. NVDA just added column/row
heading support... Kudos to the NVDA team, it gets them right as I
move about the table!

5. I made a couple of recordings. I think you'll be surprised - what
you "see" isn't what you "hear." There's hidden text (thanks to the
TITLE attribute) on the quick find and column filters. This isn't a
bad thing; it explains things to those using a screen reader, and we
can always press the "shutta-you-mouth-up" key (e.g. Ctrl) to stop
the reading of the instructions. In both recordings I have set the
option so NVDA speaks command keys, which means you'll hear things
like "Tab" and "Control+Alt+Down Arrow" when I press those keys.

Recording 1: NVDA reading the form in "Say All" mode (continuous
reading). I stopped it after reading the 3rd column heading.
http://bennett1.org/temp_stuff/filterReadForm.mp3

Recording 2: Filling-in the form. I start at the top of the page and
press Tab to move to the first check box, and we continue from there.
http://bennett1.org/temp_stuff/filterFormFill.mp3

Other than that, I think the filter is great! [he said sarcastically
:-) ] But it has room for improvement. Adding things like proper
labels, maybe a bit of ARIA-LIVE, and a GO button the filter has good
possibilities.

ARIA Examples:
http://wiki.codetalks.org/wiki/index.php/Set_of_ARIA_Test_Cases

-- Terrill --


At 08:27 PM 11/3/2010, you wrote:
>Hi folks,
>
>I'm working on a table of records and am trying to determine what
>type of filer I should use. Business requirements will influence
>this, but I'm wondering whether one option just isn't viable
>usability & accessibility-wise:
>
>1) If I use this column filtering plug-in:
>http://www.picnet.com.au/picnet_table_filter.html (try the demo),
>what would I need to check for to make sure it's accessible. I can
>certainly tab through and enter data, but I'm not sure how to
>determine whether a screen reader user could pick up on the fact
>that the table had changed in response to their typing without going
>through the entire table.
>
>2) If I use the typical View: {dropdown} which allows the user to
>filter the results by making a selection in the drop-down, is there
>any solution other than adding a clunky "Go" button that provides no
>value to a non-screen reader user (and makes the interface seem less
>responsive and modern).
>
>Any other suggestions folks have are most welcome.
>
>Thanks so much for any advice you have on this!
>Allison
>
>Allison Bloodworth
>Senior User Experience Designer
>Educational Technology Services
>University of California, Berkeley
> <EMAIL REMOVED>
>510-289-6627
>
>
>
>
>
>
>
>