(Accessibility) Kibana Logs - Calendar not navigable via Screenreader

[barlowm]

Steps to reproduce (assumes NVDA or JAWS Screen Reader or similar)

NVDA Screen Reader is a free Screen Reader which can be downloaded from the NV Access Website
Deque has a page of shortcuts for help on using NVDA as well as a Quick Reference Guide for using NVDA

Steps to reproduce

1. Navigate to the Kibana Logs page

2. Navigate to the "Date" field
   

3. Use the keyboard to navigate through the popup calendar. NVDA screen reader does not read out the location of the cursor (See attached video)

Expected Result
Screen reader should report to user the current focused element as the user navigates with the keyboard.

Meta Issue
Accessibility Audit for Kibana 7.0

Kibana Version:
7.2

OS:
Tested on Windows 7. But issue exists in all OS's

Browser:
Tested in Chrome. But issue exists in all Browsers

Screen reader: [if relevant]
NVDA

Relevant WCAG Criteria: WCAG Criterion
Navigable
Guideline 2.4: Provide ways to help users navigate, find content, and determine where they are.
1.3.1 Info and Relationships - Level A
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
Understanding SC 1.3.1

Relevant ARIA spec: WAI-ARIA Authoring Practices 1.1
N/A

[elasticmachine]

Pinging @elastic/infra-logs-ui

[barlowm]

MP4 example zipped since GIT doesn't support MP4
Kibana Calendar Navigation with NVDA.zip

[Zacqary]

Here's a state I was somehow able to get into using VoiceOver on Mac:

This is just me hitting the Tab key over and over again. I seem to have gotten locked into an infinite loop by which it's impossible to remove focus from the calendar. As you can see from the transcript, it does seem to be announcing all the options, but not in a particularly useful way.

I was able to accidentally get it into a state where VoiceOver said something like "You are on a calendar. Use the arrow keys to select date." I have no idea how I did this and wasn't able to get it to do that again.

Basically what I'm trying to say is, this is more than just a screen reader problem. This widget's keyboard interaction seems fundamentally broken too.

[Zacqary]

This is me using the arrow keys to change the date. Notice how the log entries reload immediately after I press an arrow key, which is a pain if you're trying to go back several days.

It doesn't seem to be possible to change the time in the right-hand side list box with the keyboard at all.

I almost wonder if we should replace the keyboard interaction on this element with typing a date in the text box. Maybe some additional arrow key interactions to jump between days.

@hbharding I'm gonna tag you because this feels like a UX issue now, wondering if you have thoughts.

[Zacqary]

Looks like we're mostly using stock react-datepicker here, and if you look for its issues with accessibility it's kind of a long list: https://github.com/Hacker0x01/react-datepicker/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+accessibility

Specifically the timepicker being inaccessible is a long-standing open issue: Hacker0x01/react-datepicker#1370

In light of that I'm very much leaning towards keeping the <input> box in focus and designing our own keyboard interaction based on typing the date and/or mapping arrow keys to something else, as resolving this issue upstream on react-datepicker might be difficult. We could certainly try to open a PR with our approach, though.

[hbharding]

Hey just seeing. I'm going to ping @elastic/kibana-design who maintains the datepicker so they're aware and might be able to provide some input.

I seem to have gotten locked into an infinite loop by which it's impossible to remove focus from the calendar.

You can press esc to remove focus / close the calendar. Pressing enter to confirm the selection only works if you're focused on the time selection part of the widget.

I was able to accidentally get it into a state where VoiceOver said something like "You are on a calendar. Use the arrow keys to select date." I have no idea how I did this and wasn't able to get it to do that again.

When focused on the datepicker text input, if you press the up key, it activates the calendar.

the log entries reload immediately after I press an arrow key, which is a pain if you're trying to go back several days.

I agree this is annoying. It feels like jumpy and disorienting behavior. Perhaps we should wait until the user confirms a date/time before we load new log data. Currently, EUI updates the date in the text input whenever a new date in the calendar is clicked or selected via keyboard. The only (super minor) problem I see is if a user clicks on a new date (not a time, which confirms the selection), is it confusing that the text input will show a date that is different than the logs data shown beneath the calendar widget? I may need to think on this some more / open a different ticket.

It doesn't seem to be possible to change the time in the right-hand side list box with the keyboard at all.

I figured it out! You can. But I think we have a CSS bug which doesn't show the focused style. In EUI docs, when focused on the time select, you can press up/down to change focus. See screenshot
. In our app, you can press up/down and it works, you just can't see it :)

I almost wonder if we should replace the keyboard interaction on this element with typing a date in the text box. Maybe some additional arrow key interactions to jump between days.

I'm hesitant to deviate from the EUI component. Perhaps this is worth bringing up with the EUI team. I believe EUI supports typing in a date, but you have to tab focus into the text input. Clicking on the input activates the calendar widget.

[snide]

Just for context.

• Eui's datepicker is built upon React Date Picker as linked above.
• We attempted to fix their accessibility issues, spent nearly two months on it, but had pretty bad feedback loops with the creators and instead forked it, then added accessibility on top (Using Mac voiceover as our guidepost as always). It is currently installed as a package within EUI and is heavily modified. As far as I know, we are the only people actually attempting to build a calendar with screen reader support that is browser additive. We currently do not test for JAWS.
• Focus trapping within popovers is correct accessibility. You can ESC at anytime (which is announced) and should be getting proper role announcements. Similar feedback / control exists within all EUI popovers. Everything looks to be getting keyboard focus correctly and has methods to navigate using your keyboard.
• As to screenreaders, there are a bunch of hidden voiceover messages in there that alert you to how to do the up/down arrow stuff. The reason it is finicky is because it utilizes live regions and role="alert", which are notoriously problematic, ESPECIALLY when you move quickly (you are essentially skipping the announcement of one live region and overwriting it with the announcement of another).
• This is why we ALWAYS use actual inputs for dates in addition to the visual controls. The fallback is that people can type the dates in, leaving the visual selectors optional.

Testing out this component on the EUI docs I see that the announcement for the "time" selector is not registering correctly. That is a bug. Everything else (from an announcement point of view) within OSX voiceover seems to mostly work as long as you're moving at a normal pace (which i think is a fair assumption for someone who needs to listen to the announcements). I unfortunately can't think of a better strategy there.

The logging app's issues with changes immediately effecting the loading of the logs display can be fixed by putting a button somewhere in your app and requiring the user to click it to "update" the date. This has nothing to do with the component itself, and is something you can fix in Kibana. Look to how the other apps provide buttons as triggers rather than making automatic updates.

All that said we'd love help around accessibility with the date pickers, so please feel free to make issues or submit PRs against EUI. To say it's challenging given Kibana's requirements is an understatement :) I'll see what I can do around the announcement of the time and created elastic/eui#2161 to track.

[Zacqary]

I agree this is annoying. It feels like jumpy and disorienting behavior. Perhaps we should wait until the user confirms a date/time before we load new log data.

Maybe adding a small debounce to reloading the log data on date change could work?

Anyway, thank you both for the details! I think in investigating this issue and trying to understand the whole component I got distracted from the original reported problem which was:

NVDA screen reader does not read out the location of the cursor (See attached video)

The problem on my end is that VoiceOver does exhibit the correct behavior:

whereas NVDA just seems to go silent when the user presses an arrow key.

Since I'm new to working deeply on a11y, I imagine there's probably something very wrong with this idea I'm about to propose. But my instinct is:

• Don't even use the browser's native focus behavior on a component this complex
• Override the behavior of Tab and Shift-Tab to change a focus state in React, and manually handle which elements to render with the "in focus" style
• Trap native focus in some kind of invisible wrapper element and have React update its ARIA alert as the user interacts with the component

I want to make sure all screen readers work properly with our components, but when they all implement the standards so differently I'm not sure what else to do in this situation

[barlowm]

Along with charts and maps accessible calendar controls is one of the most inaccessible controls on the web today. There have been many discussions on the topic for a long time now. But one of the most accessible ones I've found is the deque Datepicker, but even it has problems.
There's a good (relatively recent) review of a number of date pickers but even that article doesn't point to a definitive choice for an accessible date picker. Many date pickers out there use the Open Ajax Alliance as an example for an accessible date picker, but I've found a number of inherint flaws in those as well.

[Zacqary]

That's odd that the "accessibility university" would build something that still isn't fully accessible.

It seems to work okay in my testing, the arrow key controls at least work, but why does it need to tell me how many columns and rows are in the calendar? Seems like information overload IMO.

Also it's not reading out what day of the week a date is when I press the arrow keys to move the date. That's the entire purpose of laying things out visually in a calendar format, so that you can know what day of the week each number is, and it's not even reporting that. It overloads you with describing the visual metaphor but leaves out the important bit of what that visual metaphor is even for.

I think we can do way better than this. My main project is blocked right now so I think I'm gonna try hacking together a better datepicker.

[sgrodzicki]

What's the current state of this? As we have already invested quite some time to investigate this I'd love to make it actionable.

[Zacqary]

This has been a back-burner project for a while and I haven't gotten very far with it. I still think it would require building a new datepicker from scratch and not using react-datepicker at all. Since we'd only need a specific subset of features and not have to make it as configurable as react-datepicker I think that would be easier than it sounds, but still a little complex.

If that's something we want to include on the 7.6 roadmap I can focus some time on it.

[jasonrhodes]

This will be solved as we move to the EUI datepicker in #54280