dashboard tools are not accessible by keyboard, not valid for accessibility

[tassoman]

Dashboard page is missing WCAG 2.1 requisite 2.1.2

Context

When you try to move in the page by using keyboard, some tools are unreachable.

Expected Behavior

Navigation by keyboard is required for accessibility

Current Behavior

The only working tool are search field and "website selection".

• Period panel can't be focused neither opened.
• Segments panel can be focused but not opened.
• Dashboard menu can be focused but not opened.

Steps to Reproduce (for Bugs)

1. open demo site's dashboard
2. try navigation by using tabs
3. tab nav to search field, try to digit something in it
4. tab more to websites selectors, press enter to activate, try to select some website
5. tab more to other panels, they are not working at all.

Your Environment

• Matomo Version: 4.x
• PHP Version: 8.x
• Browser: any
• Operating System: any

[bx80]

Hi @tassoman,

Thanks for reporting this, I've followed the steps you provided and can confirm that keyboard navigation doesn't provide access to all the UI function.

I've assigned this issue to our product team for prioritization.

[Stan-vw]

Thanks for the report @tassoman. I hadn't used keyboard shortcuts in Matomo before seeing your report, so I'm trying to get up to speed to understand what is/isn't possible. I tried it on a cloud instance using the demo data, using Chrome on a Mac.

From the attached screenshot and some quick testing, I've been able to:

• open the period panel, and select a date range (including changing months)
• open the segments panel, and select an existing segment
• tab-nav to the search function, type something in and select it
• open the search function using f shortcut, and select various views through the search function
• open the dashboard section of the left menu (tabbing until it's highlighted and then pressing enter)
• navigate to items in the dashboard menu of the left section. Note: this was not immediately intuitive to me, I had to tab through the top level menu first before it started tabbing through the sub-level. It might be faster/easier on the arms to press f for search and type in the name of the sub-level, in case you know the name you're looking for.

I was not able to:

• get the Apply button of the period panel highlighted (I was still able to apply the selection by pressing enter while having the radio button of the period selector selected)
• change the conditions when creating a segment (would be good to understand if this is possible in another way)

I'll close this for now given I wasn't able to reproduce it, but let me know if you tried the items again and if it's now working/still not working. If it's not working: feel free to reopen 👍

[tassoman]

Even if functionality could work, for accessibility purpose the issue is not resolved.

Inside the application, there's no accessible indication about pressing the ❓ key.
The modal window have no WAI-ARIA attributes, so visual impaired person can't be sure theirs tools will "see" the guide at all. (must be tested).
The modal window have no button for closing action, usally it's an upper right ❌ button, no good for usability.
Pressing F then writing some characters, it's impossible to select any searched item from the list. Also, the list is a dynamic changing element without any WAI-ARIA attribute. (must be tested)

The calendar, also, have no WAI-ARIA attributes, it's changing its behaviour while selecting "compare" method. Navigation between days (tab-nav) is different between navigation inside radio buttons (up-down arrows)

Dashboard menu stills not accessible.

Matomo it's also a software targeted by EU public sector organizations and they have mandatory instruction by laws to serve accessible services adherent to WCAG 2.1 AA level.

https://webaim.org/techniques/aria/#dynamic

Please re-open this issue as soon as possible, I'm not able to do by myself, your workflow removed this option.

[Stan-vw]

Reopening as requested. Just checking if I understand correctly what you are missing:

• there's no indication about pressing the ? to bring up the shortcuts modal
• the shortcuts modal doesn't have an indicator how to close it (it closes when pressing Esc, but I understand a visual X in the top right corner would help)
• Dashboard menu still not accessible --> you mean the dropdown at the top to add a widget? I indeed also couldn't get that to work

Can you kindly explain what you mean with:

• The modal window have no WAI-ARIA attributes, so visual impaired person can't be sure theirs tools will "see" the guide at all. (must be tested).
• • Apologies, I'm still getting familiar with the terminology here. Can you kindly explain exactly what's missing? I.e. does a screenreader not read the text on the modal?
• Pressing F then writing some characters, it's impossible to select any searched item from the list. Also, the list is a dynamic changing element without any WAI-ARIA attribute. (must be tested)
• • I was able to select items in the search list by pressing arrows up/down + enter, so I'm not sure what's missing
• The calendar, also, have no WAI-ARIA attributes, it's changing its behaviour while selecting "compare" method. Navigation between days (tab-nav) is different between navigation inside radio buttons (up-down arrows)
• • I understand from various sources that the standard for choosing other radio button options is through up-down arrows, so that part seems alright. Should navigation between days be different? I couldn't immediately find the standard for this unfortunately.

Thanks for your input and feedback.

[tassoman]

Hi Stan, thank you for your deeper analysis on this subject. I confirm your first three dots.

Semantic web is usually enough for visually impaired person's navigation on static pages. When you have a dynamic UI changing its shape by user input, as this application does, modern development needs different approach.

In this case, frontend frameworks as VUE gives opportunity to leverage use of WAI-ARIA support so you can have accessible applications, even if using XHR, and browser scripting.

This is the scenario of Matomo, modal windows are outside linear navigation, so when they appear they must be accessible, it's the same for dynamic parts of UI.
For example alteration of forms during fields selection. If the user is aided by screen reading / accessibility tools (an iPhone or iPad, a screen reader software for PC) this tools must be informed of UI shape or content modification, if needed.

When I wrote "must be tested" it means we must internally do an accessibility audit about keyboard navigation criterion success by using "shortcuts" as you noted before. In this case, "shortcuts" can be intended enough for accessibility.

This link gives informations on general UI patterns we can also find inside matomo https://www.w3.org/WAI/ARIA/apg/patterns

About F shortcut search, I can confirm can work by keyboard but can't say it's really accessible to visually impaired. Must be tested also.

[Stan-vw]

Thank you for the extra information. Accessibility is on our mind and we've had conversations about planning an accessibility audit, I unfortunately can't give a timeline on that. As an immediate step, I'll make tickets for the 3 specific items that we've identified and I encourage you to make (separate) tickets when you identify specific items that you believe make a big difference in accessibility.

[tassoman]

We had already an accessibility audit made by professionals. Targeted WCAG 2.1 AA. But it's an italian language report.
All my issues are related to missing points from the audit.
The audit covers essentials aspect for sufficient accessibility, if you are interested an a full audit, in english, I can ask my organization about disclosure.

In our opinion, being 5.x a mayor release, it should be complaint about sufficient level of accessibility.
Maybe next minor releases can be addressed for a more accurate level.

[sgiehl]

@tassoman We would for sure be interested in seeing the results of the audit.

In our opinion, being 5.x a mayor release, it should be complaint about sufficient level of accessibility.

We are happy to fix what we can, but the 5.0 release isn't that far away, so we might need to move some fixes to the follow minor releases.

[tassoman]

We are ok with this choice but we're going to update mayor release, only after a11y integration.

Upgrading a mayor release in our process means a need for a complete new a11y audit and new security audit. Passing both is mandatory to get things done.