E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 13 (In chronological order)

From: Allison Bloodworth
Date: Wed, Nov 03 2010 6:30PM
Subject: Accessible table filtering options
No previous message | Next message →

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 ADDRESS REMOVED =
510-289-6627

From: Terrill Bennett
Date: Thu, Nov 04 2010 5:48AM
Subject: Re: Accessible table filtering options
← Previous message | Next message →

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 ADDRESS REMOVED =
>510-289-6627
>
>
>
>
>
>
>
>

From: Hoffman, Allen
Date: Thu, Nov 04 2010 2:03PM
Subject: Re: Accessible table filtering options
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED =
>510-289-6627
>
>
>
>
>
>
>
>

From: Allison Bloodworth
Date: Thu, Nov 04 2010 2:30PM
Subject: Re: Accessible table filtering options
← Previous message | Next message →

Hi,

Thanks everyone for their feedback so far, and Terrill for going way above and beyond and testing this! :)

Allen, could you elaborate on your comment? Do you mean that by tabbing to the drop-down, using the down arrow key to select a choice, then hitting enter I wouldn't need a "Go" button? I did just test that with Mac's VoiceOver and you're right it appeared to work fine.

Perhaps things have changed and now it is safe to use a drop-down without a Go button -- I just want to verify this before proceeding as it used to be standard that you needed to use a Go button in those situations (e.g. see http://webaccess.berkeley.edu/developer-tips.php#go).

Thanks!
Allison

On Nov 4, 2010, at 1:03 PM, Hoffman, Allen wrote:

> 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 ADDRESS 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 ADDRESS REMOVED =
>> 510-289-6627
>>
>>
>>
>>
>>
>>
>>
>>

From: Nathalie Sequeira
Date: Fri, Nov 05 2010 2:09AM
Subject: Re: Accessible table filtering options
← Previous message | Next message →

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

From: Allison Bloodworth
Date: Fri, Nov 05 2010 10:24AM
Subject: Re: Accessible table filtering options
← Previous message | Next message →

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

From: James Nurthen
Date: Fri, Nov 05 2010 11:00AM
Subject: Re: Accessible table filtering options
← Previous message | Next message →

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

From: Terrill Bennett
Date: Sat, Nov 06 2010 9:12AM
Subject: Re: Accessible table filtering options
← Previous message | Next message →

Y'all,

Sorry, I do NOT program in JQuery... but then, things like that have
never stopped me from making a fool of myself, before. So I thought
I'd see what I could do with this PicNet filter-thingy and ARIA-Live.

To the original PicNet demo, I:

1. I added proper labels to the check boxes in the demo.

2. I took the obfuscated JQuery source code, and started looking.
Found a place that looked hopeful.

3. Copied the ARIA-Live demo from:

http://accessibleajax.clcworld.net/simple/controls.htm

4. Merged the demo code from PicNet with the demo above.

5. Researched a wee bit on "How to" do some JQuery stuff on Google.

6. Hard-coded (kludged) an example. (It's easy to find in the .js -
it's the part with statements on separate lines).

Results:

http://bennett1.org/temp_stuff/filterTest.htm

In my recording of NVDA, I tabbed through the form starting at the
top. I allowed SOME of the instructions to be read, but didn't wait
for it to complete - I moved on by tabbing until I eventually reached
Text Column 1. You will (sometimes) hear NVDA say things like "tab" as I move:

1. When I reach the Quick Find, I press Tab and move to the Clear Filters link.

2. I press Tab again to reach the Text Column 1, I pause. I press
Ctrl (not heard) to stop reading the instructions, and we hear "50
rows" from the ARIA-Live update.

3. In Text Column 1, I then type 9. We hear "10 rows" (more on this
count in a second - see NOTE below).

While I didn't record it, I did continue to the Select list, picked
Item 1, hit Enter, and the rows reduced count, and NVDA announced the
new row count. You'll have to trust me!

NOTE: I seem to have found a slight bug, uh, I mean "undocumented
feature" in the filter. If you go to the ORIGINAL demo from Picnet,
type 9 in Text Column 1, you'll get some number of rows (I think at
first I got 12?). Clear the filters using the link, back to Text
Column 1, type 9, get a different count. Reload the page, repeat, you
will probably get a different count, again. Weird.

Anyway, I seem to have made SOME progress. Perhaps someone who
actually knows JQuery can make it better. Links to the ZIPped files
(htm, modified .js and MP3) are at the bottom of the page.

Enjoy!

-- Terrill --

"Man who says it cannot be done, should not interrupt man who is doing it."
-- Ancient Chinese Proverb

From: Terrill Bennett
Date: Sat, Nov 06 2010 11:12AM
Subject: Re: Accessible table filtering options
← Previous message | Next message →

Well, it IS Saturday...

I failed to mention that the filter+ARIA works in the following combinations:

* NVDA2010.2 + Firefox 3.6.12 (a popular combination)
* JAWS 11.1447 + IE8 (an even more popular combination)

It does not work with:

* NVDA2010.2 + IE8
* JAWS 11.1447 + Firefox 3.6.12

But then, who would expect otherwise?

Also, I did more testing of the "Clear Filters" and reloading the
page issues, with both the ORIGINAL filter on the PicNet site and my
kludged filter. The bad news is: Yes - the filtering is flaky at
best. The good news is: my kludge seems to get the number of rows
correct after a change. I'm not sure I'd use the filter in either
form on a production site. My humble opinion, of course! <G>

I return you now to the Wisconsin vs Purdue game, which is already in
progress...

-- terrill --

"If at first you don't succeed, failure may be your style."
-- A Not-So Ancient American Saying
http://www.despair.com/los24x30prin.html

From: Terrill Bennett
Date: Sun, Nov 07 2010 6:09AM
Subject: Re: Accessible table filtering options
← Previous message | Next message →

It was Saturday.

Today is Sunday. Time change. Extra hour of sleep. Re-test. Results...

DUH! When you reload the JQuery Table Filter page, the data is
randomly generated. Well, now ain't that sweet? And, wouldn't that
account for the different number of rows when you filter? YA THINK?
[Insert flame here]

The filter works fine. "User error. Replace user."

Coffee. Need more C8H10N4O2.

-- terrill --

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."
-- Brian W. Kernighan

From: Allison Bloodworth
Date: Mon, Nov 08 2010 4:12PM
Subject: Re: Accessible table filtering options
← Previous message | Next message →

Wow, Terrill, thanks so much for trying this out for us! It would seem to me that ARIA-Live would be what we want, as Live Region's description here: http://juicystudio.com/article/wai-aria-live-regions.php is:

"AJAX live regions allows text to be spoken without giving it focus. This is good in that it means that users can be informed of multiple updates without losing their place within the content. The following attributes are defined in the States and Properties module that relate to AJAX live regions."

However, I'm not experiencing anything other than the addition of the "Row count" line in the text with Mac's VoiceOver. I'm not sure ARIA is supported in VoiceOver, so that may be the problem. Terrill, did you actually record what you heard with the other screen readers you tested somewhere? Was there some sort of interruption (I'm assuming it would probably happen after the user entered text into one of the filter fields, then left the field) that told you the number of table rows had changed?

Does this seem to others what this table would need to be accessible?

Thanks!
Allison

On Nov 6, 2010, at 8:11 AM, Terrill Bennett wrote:

> Y'all,
>
> Sorry, I do NOT program in JQuery... but then, things like that have
> never stopped me from making a fool of myself, before. So I thought
> I'd see what I could do with this PicNet filter-thingy and ARIA-Live.
>
> To the original PicNet demo, I:
>
> 1. I added proper labels to the check boxes in the demo.
>
> 2. I took the obfuscated JQuery source code, and started looking.
> Found a place that looked hopeful.
>
> 3. Copied the ARIA-Live demo from:
>
> http://accessibleajax.clcworld.net/simple/controls.htm
>
> 4. Merged the demo code from PicNet with the demo above.
>
> 5. Researched a wee bit on "How to" do some JQuery stuff on Google.
>
> 6. Hard-coded (kludged) an example. (It's easy to find in the .js -
> it's the part with statements on separate lines).
>
> Results:
>
> http://bennett1.org/temp_stuff/filterTest.htm
>
> In my recording of NVDA, I tabbed through the form starting at the
> top. I allowed SOME of the instructions to be read, but didn't wait
> for it to complete - I moved on by tabbing until I eventually reached
> Text Column 1. You will (sometimes) hear NVDA say things like "tab" as I move:
>
> 1. When I reach the Quick Find, I press Tab and move to the Clear Filters link.
>
> 2. I press Tab again to reach the Text Column 1, I pause. I press
> Ctrl (not heard) to stop reading the instructions, and we hear "50
> rows" from the ARIA-Live update.
>
> 3. In Text Column 1, I then type 9. We hear "10 rows" (more on this
> count in a second - see NOTE below).
>
> While I didn't record it, I did continue to the Select list, picked
> Item 1, hit Enter, and the rows reduced count, and NVDA announced the
> new row count. You'll have to trust me!
>
> NOTE: I seem to have found a slight bug, uh, I mean "undocumented
> feature" in the filter. If you go to the ORIGINAL demo from Picnet,
> type 9 in Text Column 1, you'll get some number of rows (I think at
> first I got 12?). Clear the filters using the link, back to Text
> Column 1, type 9, get a different count. Reload the page, repeat, you
> will probably get a different count, again. Weird.
>
> Anyway, I seem to have made SOME progress. Perhaps someone who
> actually knows JQuery can make it better. Links to the ZIPped files
> (htm, modified .js and MP3) are at the bottom of the page.
>
> Enjoy!
>
> -- Terrill --
>
> "Man who says it cannot be done, should not interrupt man who is doing it."
> -- Ancient Chinese Proverb
>
>

From: Terrill Bennett
Date: Mon, Nov 08 2010 6:27PM
Subject: Re: Accessible table filtering options
← Previous message | Next message →

Allison,


> Wow, Terrill, thanks so much for trying this out for us!

My pleasure! I contacted the original JQuery Filter author, Guido
Tapia. As with many developers, ARIA-Live is a new concept. But he's
going to look into adding the changes to his filter. Fingers crossed!

> However, I'm not experiencing anything other than the
> addition of the "Row count" line in the text with Mac's
> VoiceOver. I'm not sure ARIA is supported in VoiceOver, so

Unfortunately, I don't do Apples (I did own a Lisa, once). I have no
idea what the current status is for ARIA support, today. WebAIM has
an article that the footer says was last updated in January of 2010.
It says VoiceOver failed:

http://codetalks.org/wiki/index.php/Set_of_ARIA_Test_Cases#aria-live

> ...did you actually record
> what you heard with the other screen readers you tested
> somewhere?

I hadn't then, but I have now. And I only stumble around with two
readers: NVDA and JAWS. New links to new recordings further below...

> Was there some sort of interruption (I'm assuming
> it would probably happen after the user entered text into one
> of the filter fields, then left the field) that told you the
> number of table rows had changed?

ARIA-Live comes in flavors: off, assertive and polite.
http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-live
or: http://goo.gl/qPcU2

* In my original recording, assertive was being used. The reader
is supposed to stop what it's doing and announce the updated value of
the ARIA-Live region, so interruptions are supposed to happen if
you're a slow typist (and I am). There is a demo with a good
explanation of ARIA-Live using assertive, here:
http://accessibleajax.clcworld.net/simple/live_assertive.htm
or: http://goo.gl/0wLTX

* With polite, as explained in the link below, if the screen
reader is busy reading text you won't hear the counter in their demo
as it changes. When you command the reader to stop reading the page,
the numbers are again announced as they change. And no, the "missed"
numbers aren't stored and read later. Here is their demo and good
explanation of ARIA-Live using polite:
http://accessibleajax.clcworld.net/simple/live_polite.htm
or: http://goo.gl/UWWLx

JAWS seems to be a bit more tolerant than NVDA when "polite" is being
used while >> I << type in a filter. Again, I'm a slow typist - I get
a few announcements even with polite.

My recordings and demos have grown:

(New) Filter demo using polite:
http://bennett1.org/temp_stuff/filterTestPolite.htm

(New) NVDA, polite:
http://bennett1.org/temp_stuff/filterTestPoliteNV.mp3

(New) JAWS, polite:
http://bennett1.org/temp_stuff/filterTestPoliteJaws.mp3

(Old) Filter demo using assertive:
http://bennett1.org/temp_stuff/filterTest.htm

(New) JAWS, assertive:
http://bennett1.org/temp_stuff/filterTestJaws.mp3

(Old) NVDA, assertive:
http://bennett1.org/temp_stuff/filterFormFill.mp3

Hope this helps!

-- Terrill --

PS: for our music fans, try a different kind of ARIA (courtesy of Guido Tapia):
http://www.ariaawards.com.au/home.php

From: Dean Hamack
Date: Mon, Nov 08 2010 8:00PM
Subject: Re: Accessible table filtering options
← Previous message | No next message

On 11/8/10 6:23 PM, "Terrill Bennett" < = EMAIL ADDRESS REMOVED = > wrote:

> Unfortunately, I don't do Apples (I did own a Lisa, once). I have no
> idea what the current status is for ARIA support, today. WebAIM has
> an article that the footer says was last updated in January of 2010.
> It says VoiceOver failed:

Just an FYI: Apple is very good about responding to questions and concerns
with regards accessibility. I sent them an email regarding iPhone
accessibility once and they responded within a day. If you find problems,
it's worth dropping them a note.