WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Javascript table filtering question

for

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

From: Jeremy Echols
Date: Tue, Apr 30 2019 12:05PM
Subject: Javascript table filtering question
No previous message | Next message →

Hi, we're hoping for some advice on the following scenario:

- We have a web page that contains a table showing newspaper titles
- The first column is the actual title, the remaining cols have information pertaining to the title
- There are over 200 rows
- The product owner would like there to be a way to find a title without using ctrl-f

We have added a text field and reset button, and we're using jquery to filter what rows are displayed:

- A user begins typing into the text box
- As the user types, any row that does not contain the string in the first col is hidden (the row now has style="display:none;")
- The reset button clears the text box and makes all rows visible again

Beyond ensuring that the form elements are correctly added to the page, are there any accessibility issues that we might need to address?

From: Jared Smith
Date: Tue, Apr 30 2019 12:26PM
Subject: Re: Javascript table filtering question
← Previous message | Next message →

Jeremy Echols wrote:

> Beyond ensuring that the form elements are correctly added to the page, are there any accessibility issues that we might need to address?

It sounds like you've considered the issues. The updating table
shouldn't pose an issue because it can only update when they are in
the filter text field. It may take some orientation to realize that
the table is auto-updating - most forms would have a button to perform
the action. I don't see this as a critical issue - especially if there
are instructions and/or a good label ("Filter titles in the table
below" or similar).

You might consider an ARIA live region to indicate the filtering
status ("27 titles found" or similar) after perhaps a second of
inactivity in the search field. This would be especially helpful if
they filter out all results - they would know this without having to
navigate the table.

Jared Smith
WebAIM.org

From: Birkir R. Gunnarsson
Date: Wed, May 01 2019 7:05AM
Subject: Re: Javascript table filtering question
← Previous message | Next message →

We've been implementing similar tables.
We do have a screen reader descrption that "typing into this field
filters the search results table".
Use aria-describedby to reference the elemen with those instructions,
you can even hide it with isplay: one; (because aria-describedby
overrides display: none;)
<label for="search">Search<label>
<input id="search" aria-describedby="srText">
<span id="srText" style="display: none;">Typing into this field
filters the search results table by title</span>

Like Jared said, you could have a visually hidden live region that
indicates how many results were found (you can use the number of
visible <tr> elements minus one (the row with the headers).

<div class="srOnly" aria-live="polite" aria-atomic="true">
<span id="resFound"> <span> titles displayed.</div>

srOnly would be a CSS class that hides text visually, you can Google
screen reader only content. This organization called WebAIM, or
something, has an article on it that isn't all awful. *grin*

aria-live="polite" tells screen read to announce the text when the
span is updated
aria-atomic="true" forces the screen reader to read the whole content
of the div (including the text), else it would only read the number
when it is updated, you can take that approach to if you prefer.



On 4/30/19, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> Jeremy Echols wrote:
>
>> Beyond ensuring that the form elements are correctly added to the page,
>> are there any accessibility issues that we might need to address?
>
> It sounds like you've considered the issues. The updating table
> shouldn't pose an issue because it can only update when they are in
> the filter text field. It may take some orientation to realize that
> the table is auto-updating - most forms would have a button to perform
> the action. I don't see this as a critical issue - especially if there
> are instructions and/or a good label ("Filter titles in the table
> below" or similar).
>
> You might consider an ARIA live region to indicate the filtering
> status ("27 titles found" or similar) after perhaps a second of
> inactivity in the search field. This would be especially helpful if
> they filter out all results - they would know this without having to
> navigate the table.
>
> Jared Smith
> WebAIM.org
> > > > >


--
Work hard. Have fun. Make history.

From: Josh Schroder
Date: Wed, May 01 2019 8:11AM
Subject: Re: [ External Email ]Javascript table filtering question
← Previous message | No next message

Hi Jeremy,

I did a similar project a while back (jQuery DataTables), and one thing I ran into with testing was the delay between when the user stops typing and when the aria-live region starts announcing results.

It can be very annoying if someone is a slower typist and the live region wants to start announcing search results between each keystroke.

I got around this by setting a delay of about 400ms and deferring processing the results until after that delay. This also improved the performance of the application in relation to CPU/memory usage and made it feel faster in spite of the delay.

Hope that's helpful.

Josh Schroder

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Wednesday, May 1, 2019 8:06 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [ External Email ] Re: [WebAIM] Javascript table filtering question

'
CAUTION: This email originated from outside of the organization! Do not click links, open attachments or reply, unless you recognize the sender's email address and know the content is safe!
'

We've been implementing similar tables.
We do have a screen reader descrption that "typing into this field filters the search results table".
Use aria-describedby to reference the elemen with those instructions, you can even hide it with isplay: one; (because aria-describedby overrides display: none;) <label for="search">Search<label> <input id="search" aria-describedby="srText"> <span id="srText" style="display: none;">Typing into this field filters the search results table by title</span>

Like Jared said, you could have a visually hidden live region that indicates how many results were found (you can use the number of visible <tr> elements minus one (the row with the headers).

<div class="srOnly" aria-live="polite" aria-atomic="true"> <span id="resFound"> <span> titles displayed.</div>

srOnly would be a CSS class that hides text visually, you can Google screen reader only content. This organization called WebAIM, or something, has an article on it that isn't all awful. *grin*

aria-live="polite" tells screen read to announce the text when the span is updated aria-atomic="true" forces the screen reader to read the whole content of the div (including the text), else it would only read the number when it is updated, you can take that approach to if you prefer.



On 4/30/19, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> Jeremy Echols wrote:
>
>> Beyond ensuring that the form elements are correctly added to the
>> page, are there any accessibility issues that we might need to address?
>
> It sounds like you've considered the issues. The updating table
> shouldn't pose an issue because it can only update when they are in
> the filter text field. It may take some orientation to realize that
> the table is auto-updating - most forms would have a button to perform
> the action. I don't see this as a critical issue - especially if there
> are instructions and/or a good label ("Filter titles in the table
> below" or similar).
>
> You might consider an ARIA live region to indicate the filtering
> status ("27 titles found" or similar) after perhaps a second of
> inactivity in the search field. This would be especially helpful if
> they filter out all results - they would know this without having to
> navigate the table.
>
> Jared Smith
> WebAIM.org
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.