[BUG] Areas in the OpenSearch Dashboards GUI violate WCAG2.2 guidelines

[jpelletier412]

Describe the bug

A customer of ours produced a report defining areas in the GUI which viloate WCAG2.2 guidelines. The main areas deal with keyboard operation, color contrasts, and zooming. I have attached their report to initially start the disucssion. I can generate individual issues for each item if that makes it easier to manage. Is this something that can be scheduled to be addressed realtively soon?
Note: We were able to fix item [5] since this is handled in the custom branding.

Expected behavior
GUI adheres to WCAG2.2 guidelines

OpenSearch Version
2.9.0

Dashboards Version
2.9.0

Accessibility_Check_2024-01-10.pdf

[AMoo-Miki]

@kgcreative could you please review these and prioritize them?

[jpelletier412]

Hello @AMoo-Miki @kgcreative. Thank you for responding and starting investigation. Has anything progressed regarding these items? Do you need anything else from my end?

[AMoo-Miki]

@jpelletier412, we prioritized a few workstreams and fixed a bunch of issues as a result of your report. There are still some items that we would like to work on but here is an update for you.

[1] Application is not completely accessible via keyboard

We have talked about this but a plan is pending.

[2] Graphical control element without tooltip

The 5 elements mentiond, all have aria-label attributes. I am almost sure they always existed but I verified them in 2.11.1.

[3] The keyboard focus indicator is not clearly visible
[4] Color contrast of text is not sufficient
[6] Color contrast of graphical objects is not sufficient

We did a careful color selection when designing the Next theme which was made default with the 2.10.0 release.

[5] Color contrast of graphic control elements is not sufficient

Changes were made in 2.10.0 to correctly select the logo.darkModeUrl from the provided branding config for the top band.

[7] Content is cut off when website is enlarged to 200%

We have not discussed a solution for squished panels or clipped texts. I have been pitching the idea of configurable minimum and fixed-widths for Dashboard panels internally but have not formalized into into an RFC. A bug that prevented the menu from appearing was also fixed.

[jpelletier412]

@AMoo-Miki Sorry for the delayed response. I really appreciate the update and steps to continue discussing fixing remaining items. We just recently upgraded to v.2.14.0 so it looks like items 2,3,4,6 have already been addressed and we can confirm with our client. We were able to fix item 5 on our end by updating the logo we use. Thanks again for your efforts in improving the accessibility!

[jpelletier412]

@AMoo-Miki I had a follow up question. In regards to items 1 and 7, how long does this process normally take? Are we within weeks, months or no timeframe as of yet? We understand if it is difficult to be precise on a delivery but if we could get some sense of a timeframe if there are ones, that would be very helpful. Thanks again.

[AMoo-Miki]

@jpelletier412 due to large number of interfaces, [1] will be a work-in-progress for a very long time. However, it would be great if we could prioritize these so we could break the task down into smaller ones. I think the basic navigation using the left menu will be the most important one but what are the most important interfaces that your users would need to have accessible using a keyboards?

Sadly neither have a timeframe yet but the addition of this issue to the Roadmap is a positive indicator that it is getting the attention it needs.