Upgrade ui components to meet minimum accessibility standards

[cooper-joe]

This topic is based on a discussion in the 17/02/21 frontend initiatives meeting regarding accessibility (a11y) in the ui library. There was general agreement that ui should meet some minimum standards for a11y.

This proposal suggests the following order of work:

1. Define a minimum standard of a11y. (Covered in this document).
2. Identify ui core components that do not meet our defined a11y minimum standard. (Covered in this document).
3. Update ui core components to meet minimum standards.
4. If step 3 is successful, identify ui widget and other components that do not meet a11y minimum standard.

1. a11y minimum standard

I propose defining the minimum standard (derived from relevant WCAG AA points) as:

• not blocking default browser behaviour.
• allowing reasonable keyboard navigation to, and activation of, all interactive elements.
• exposing the role attribute

2. core components not meeting minimum standard

The following core ui components do not meet the minimum standard:

Chip

General

• Cannot tab to chip. A chip is an interactive element, it should be possible to focus and activate via keyboard.

Type: removeable

• Cannot tab to 'remove' action. A removeable chip has an extra interactive element used to trigger the remove action. It should be possible to focus and activate this action via keyboard.

MenuItem/Menu

• Cannot tab to MenuItem inside Menu. MenuItem is an interactive element, it should be possible to focus and activate via keyboard.

Tab/TabBar

Scrolling tabs

• A scrollable TabBar has buttons to scroll the TabBar left and right. It is not possible to tab to these buttons or activate them via keyboard. These buttons are interactive elements and it should be possible to focus and activate via keyboard.

Tooltip

• It is not possible to trigger a Tooltip via keyboard. A Tooltip trigger is technically an interactive element. Tooltips currently display on hover only. Ideally, Toolips applied to an focusable element should be displayed when said element has focus.

AlertBar

• The "dismiss" action of an AlertBar is an interactive element, and should therefore be possible to focus and activate via keyboard. I am unsure how the AlertStack will interact with the page content tabOrder, so this may be an exception to the standard.

SingleSelect

• While it is possible to trigger the dropdown using the space, up or down keys it is not possible to select options in the dropdown using the keyboard. Moreover, the native behaviour of using the up or down keys on a select is to scroll through the options provided but our component does not replicate this behaviour.

Modal

See #247

[paschalidi]

I was wondering if it made sense for us to include Modal in the list or is it perhaps that Modal isnt reaching the minimun requirements?

In our modal we can use tab to navigate which is already a good starting point. Few more things that could make it even more accessible is the following:

1. use esc to close the modal.
2. I am quoting this source for this one. In the case user is using tab to navigate, "When focus is on the last focusable element in the dialog, moves focus to the first focusable element in the dialog". This will create a sort of loop when you pressing tab. This way the focus wont be going in the background of the page while you have the modal open but will always stay on focusable elements that modal itself has.

Let me know your thoughts.

[cooper-joe]

I think it does make sense to include modal, thanks for the suggestion.

Regarding the points above:

1. I do not think Esc should close the modal by default. I think this is a useful pattern, but I don't think it is required to meet the minimum a11y standards outlined above. It should be possible to navigate with keyboard to one of the modal actions (either the confirmation action or the cancel action) - so this covers the functionality. I think there are too many edge cases to consider with Esc to close (what happens if there is unsaved data, what if Esc is used for some reason on a focused element inside the modal?), so I think this should be kept simple. I am open for allowing Esc to close in some situations, but I don't think it should be included on all modal components.
2. Agree with this one, I've added it to the document above.

[paschalidi]

Thanks for looking into it Joe! :) On the 1. esc seems indeed complicated. On the other hand it is what is being suggested by the wai aria here. In any case I only wanted to bring this to your attention I understand if this is not something for us at this point.

[cooper-joe]

Good point @paschalidi - the WAI ARIA does include esc. If we all agreed that following WAI-ARIA guidelines should be added to the defined minimium a11y standards (suggested in another thread here) then we would want to include this. I think we'd also want to include our own guidelines for how to handle discarding data on esc, I see no mention of this in the WAI-ARIA, which I find odd.

[paschalidi]

Right, makes sense thanks for taking the time to explain Joe

[Mohammer5]

For reference: I did some quick research if 2. could be solved while keeping the component in ui-core.
It think it can be done, see https://bitsofco.de/accessible-modal-dialog/

[amcgee]

Great overview @cooper-joe !

Regarding the TabBar / Tabs, we discussed removing the tabstop from individual tabs (the tabbar itself has a single tabstop) and supporting left/right arrowkey navigation between tabs - this allows the user to tab into the contents of the tab pane after selecting the tab they want. See #223

[cooper-joe]

I agree that moving to this WAI-ARIA recommended tab pattern would be ideal, however it is not strictly required to satisfy the minimum a11y standards as outlined above. I tried to keep the issues above limited to only "hard fails".

I think it might be reasonable to add "follow WAI-ARIA guidelines" to the minimimum a11y standards, reclassifying this as a "hard fail".

[ismay]

I would like to add to the minimum: we should allow adding role attributes to components (where that attribute makes sense). Currently this, for example, doesn't work (see the role attribute):

[ismay]

Some useful docs on the subject:

• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques
• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles

@Mohammer5 If I'm interpreting the above correctly, then yes, role is valid on all elements. Though relying on using the proper element semantics is preferred to using ARIA roles:

Authors must assign an ARIA role and the appropriate states and properties to an element during its life-cycle, unless the element already has appropriate ARIA semantics (via use of an appropriate HTML element).

[Mohammer5]

We could use an Element component, that accepts the defined ARIA roles (and other attributes with their respective values) as well as a tag name, which we could use throughout the core library,

That way we wouldn't have to share prop type definitions, create helper functions or have a lot of duplicated code.

What do you think about that?

[ismay]

I think that for the base components that basically resemble html elements with a bit of additional styling, I'd be in favor of just forwarding all props to the html element the component wraps. So like the button, the table components, etc. I was kind of against that initially, but I think for basic components that just add styling it simplifies things a lot. Base components are used in such a wide variety of usecase that it's not doable for us to manually cover all of them (well).

I personally think we currently have way too much logic for our base components, where I think the user should be responsible for implementing that logic (or we could do it higher up in the lib for common usecases). That seems more flexible and simpler to me.

[Mohammer5]

Sounds good to me, forwarding props -> 👍

[ismay]

As to how we'd deal with props that have special styling purposes. Say, like the primary, secondary flags on a button, etc. We could just pick those out of the props, use them internally for setting conditional styles and not forward them. That's what you'd do with styled-components and what I love about how that lib works. It forces you to only use props for styling, and does not allow you to implement any other type of logic.

That way you're automatically separating "styled" components, from components that do something. Which seems like a good distinction to me between core components (only implement styles), and components that live higher up the hierarchy (can have behaviour).

[cooper-joe]

I propose another addition to the minimum standard:

• all text displayed by a component must meet the WCAG AA contrast ratio of 4.5:1 (excepting disabled or inactive states, as outlined by WCAG2.1, though it's worth meeting standards here where possible)

[ismay]

I find point 2. from the top comment a bit hard to contribute to without further research. I didn't realize for example that our switch is not necessarily accessible if you use it without a label (like we do in the scheduler). There is a standard (https://www.w3.org/TR/WCAG20-TECHS/ARIA14.html) that provides guidelines on providing an invisible labels where a visible label cannot be used, but the switch needs to be updated to fit that standard (we need to use an aria-label attribute). This goes for the X that closes alerts as well for example, etc.

I suspect that there are a ton of issues like this in ui, that we currently don't know about. So maybe we could define the goal as: update our tests to use https://testing-library.com/docs/cypress-testing-library (and related libs), and update components where they don't allow for usage with the selectors from that lib? That should already take care of a fair amount of accessibility issues I suspect, and is still a fairly concrete goal.

Or maybe we could use the above as a follow up goal.

[ismay]

Other than this comment @cooper-joe's suggestions sound good to me. I'd be on board with starting to implement them ✅

[ismay]

One other big accessibility issue that I had almost forgotten about: using buttons as links (so a button that calls history.push on click). See this article: https://www.webaxe.org/proper-use-buttons-links. Quite bad for accessibility.

We should be using an <a> for all our links. Reason we don't do that now, is because in our designs we sometimes have navigation that looks like a button. That shouldn't be a big problem, as we can just style a link to look like a button. That way we still leverage the underlying link semantics (and all its accessibility benefits), whilst also having the look we want.

However, it's tricky to resolve that from an app, as you can't easily apply the button styles from ui to a react router Link. On the other hand, from ui, you can't easily export a styled react router link. So that's why this hasn't been solved yet (unless I'm missing something). So worth looking into.

[cooper-joe]

Agreed! I also touched on this in the discussion about pointers in ui.

I think the misuse of buttons as links would violate the first point in the minimum standard: "not blocking default browser behaviour". So I think these changes would be needed if we adopt that standard. Sounds like it is not as straightforward as adding a <Link> styled like a button though.

[Mohammer5]

However, it's tricky to resolve that from an app, as you can't easily apply the button styles from ui to a react router Link

The Link component has a component prop that can be used. So that shouldn't be an issue.

---

adding a styled like a button

My preferred approach would be to add a prop to the button that will just make the button render an anchor element instead of a button, then we keep the button styles in one place

[ismay]

Yeah it shouldn't be as hard as I thought initially. Allowing the user to swap out the underlying component should be quite doable. To me something like say, <LinkButton>, makes sense. The usage of a button and a link is slightly different, so having separate components makes sense I thought. We could then accomplish the sharing of the styles internally.

[ismay]

Maybe a good example for us is this accessible react component lib: https://reach.tech.