Queue: When a column has a filter applied, AT does not read to users that a filter is applied.

[alisan16]

The state of the Filter elements Task, Types and Docket is not read by assistive technology programs. If a filter is applied, visually a user can see this change has been applied to the data, however this change is not read by assistive technology programs. It should read "Column_name filtered by filter_criteria". (New: 08/21/2019) in caseflowdemo (under Queue/your queue/assigned)

[lowellrex]

Is the issue here that the "Filtering by: Case Type (1)" text is not being read, or that when the "Type(s)" column heading is read, there is no indication that a filter has been applied?

[alisan16]

I believe it is the latter, that when the column heading is read, the state of the filter isn't being described. There was also an open question of whether the filter itself could be applied using keyboard navigation (primarily tab, and ctrl+alt+arrow within a table). cc @carodew

This was the description provided to us:

"The state of the Filter elements Task, Types and Docket is not read by assistive technology programs. If a filter is applied, visually a user can see this change has been applied to the data, however this change is not read by assistive technology programs. (New: 08/21/2019) in caseflowdemo (under Queue/your queue/assigned) – I couldn’t get it to function in Chrome"

[hschallhorn]

@alisan16 What should we return for multiple filter selections? Should we add "and"s in between? Build a grammatically correct list? What's your take on the oxford comma?

[alisan16]

Completely up to you! Either of those options sounds good to me.

[araposo-tistatech]

reopening as this has not been resolved per the latest audit:

"I couldn’t get it to function in Chrome (3/26/2020 I was able to get to the filter but it was not read by JAWs once I activated (checked the box) of a filter)"

[ajspotts]

@araposo-tistatech Using Chrome, JAWS was able to successfully read the filter option. In the screenshot you can see the red box (which is indicative of JAWS focus) highlighting the filter.

[araposo-tistatech]

@chandracarney please see Alec's note above and advise how we should move forward. We are unable to replicate the issue.

[carodew]

I think what this is saying is that when a filter is currently in effect that the screen reader should announce what filter is applied when the header cell for that column receives focus, so that the user knows that there is a filter applied (versus the table showing all data). Worth confirming with Linsey, though.

[ajspotts]

I believe there are 2 separate issues, 1 from the original audit (listed in Alisa's issue description) and then the issue that Ann-Marie mentioned from the most recent audit when she re-opened this issue. Alisa's issue describing the problem with the column header was taken care of in a PR from Hunter. Ann-Marie's issue from the newer audit (filter not read by JAWS when activated) is what I was referencing. Hope that provides some clarity instead of more confusion! I'm adding the full description of the original and updated issues from the Caseflow a11y issues doc:

The state of the Filter elements Task, Types and Docket is not read by assistive technology programs. If a filter is applied, visually a user can see this change has been applied to the data, however this change is not read by assistive technology programs. (New: 08/21/2019) in caseflowdemo (under Queue/your queue/assigned) – I couldn’t get it to function in Chrome (3/26/2020 I was able to get to the filter but it was not read by JAWs once I activated (checked the box) of a filter)

[chandracarney]

@ajspotts Thanks for checking in! I haven't had a chance to test this out on my own, but I do wonder if this part was taken care of by @sahalliburton's recent changes in #14513? Though not yet merged, I know there was a big overhaul of how tables work for screen readers.

If not, I am happy to 1) make some time to test myself to understand behavior, and 2) check in with Linsey for more context or and test if this has been resolved.

[alisan16]

Potential duplicate of #12902, blocked until we get further confirmation from Section 508

[ajspotts]

Potential duplicate of #12902, blocked until we get further confirmation from Section 508

@alisan16 @jimruggiero I see that we've closed the other issue that was also awaiting confirmation. Do we know if we can go ahead and close this one as well?

[jimruggiero]

Hi Alec, Thanks for the follow up. We don't know yet. I will reach out to Linsey and let you know when I hear back. Thanks, Jim

…

On Thu, Jun 25, 2020 at 4:43 PM Alec Spottswood ***@***.***> wrote: Potential duplicate of #12902 <#12902>, blocked until we get further confirmation from Section 508 @alisan16 <https://github.com/alisan16> @jimruggiero <https://github.com/jimruggiero> I see that we've closed the other issue that was also awaiting confirmation. Do we know if we can go ahead and close this one as well? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12134 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMQLBLGDNI7DMQIH45UOYS3RYOZHRANCNFSM4IXU66FQ> .

[araposo-tistatech]

@ajspotts Lindsey has confirmed that this is not a duplicate. In this case the state needs to be read that a filter is applied for 12902 the issue is about being accessible via the keyboard.

[ajspotts]

Closing after confirming with @araposo-tistatech during JAWS testing walkthrough that the filter options are correctly being announced