Second round for accessibility feedback

[ckrina]

Problem/Motivation

Recent interviews and research exposed pain points around Drupal's admin experience of looking and feeling dated, especially compared to our competitors, and universally cited that choosing a more modern-looking admin theme instantly led to Drupal being better-perceived by said users.

Proposed resolution

The Seven refresh is part of the Admin UI and JS modernization initiative. Since building a completely new UI will take some time, we’re looking for a short-term improvement for the current UI changing Seven styles based on the new Design System. After fixes suggested on this round, we'd like to post an issue on drupal.org to get feedback from all the community and to try get something ready for 8.7.

Your feedback

We are on an alpha phase of this redesign, where we've defined most of the components taking into account some previous feedback. We've created this issue to gather a first round of accessibility feedback to be sure we don't move forward on the Design System with any big accessibility issue. We'd like to get your feedback here on this issue or on the Figma file itself (with the built-in comments option) to get track of your inputs, but you can also ask us any question on the Drupal slack channel #admin-ui.

Material to review

Pages

We have several designed components and we're composing pages with them. We're attaching those here as PNG, but you can review them on this Figma file too to see colors and sizes (to see colors&sizes in Figma and comment there you need to be logged in).

More pages: seven-accessibility-feedback.zip

Components

But the real work has been done on components, and it's about them that we’d like to focus most of the feedback. You can check them on this Figma file to to see colors, sizes and detailed specifications.

[fuzzbomb]

I'm having immense difficulty using Figma. I just don't understand how to operate it.

I think I can see some components on the figma document which aren't in the screenshots on this Github issue. Is there a red button with a blue outline?

I think the list of colour codes isn't complete.

• Are there two or three shades of red being used? The list of colours only has one.
• What's the blue shade used for the focus outlines on the buttons? It's not mentioned in the list of colour codes.
• I think I can see some pale pinks too, on some button backgrounds?
• The list of colours is useful, but I'm not sure if I can tell which is being used in any particular place. For instance, I can see that a text field has a blue border when it has focus, but which shade of blue is that?

[fuzzbomb]

The focus styles need work, they're too subtle. I used an eyedropper, and found the pale blue focus outline is #b3c9f5. That only has a contrast of 1.66:1 (https://contrast-ratio.com/#%23b3c9f5-on-white).

To pass WCAG success criterion 1.4.11 Non-text Contrast, the focus outline here would need to have a contrast of 3:1 against the white page background, AND also needs a 3:1 contrast against the button background colour. (That's because the focus outline is directly next to the button. That's my understanding of SC 1.4.11 - I'll ask for a second opinion about that in the W3C a11y Slack.)

It could be easier if the focus outline didn't touch the button background, then it would only need to have contrast against the surrounding container background.

[fuzzbomb]

On the drop-down selects, it has a style for "Active element (previously selected)". What's that for, and how is it supposed to behave? I don't think this is something we encounter on native dropdowns in desktop OS.

[fuzzbomb]

One of the text fields (in the screenshots here) has a warning triangle icon when it has an error message, but elsewhere another text field has an error message without a warning triangle. Is this intentional? There's also a select element with an error message, and that doesn't have a warning triangle.

[ckrina]

Thank you for the review @fuzzbomb !

• Are there two or three shades of red being used? The list of colours only has one.
• What's the blue shade used for the focus outlines on the buttons? It's not mentioned in the list of colour codes. Right, I'll update the color palette because I'm introducing similar Seven messages for now, so I have to add those colors. And the blue hover one and the secondary danger too, thanks for the reminder!
• The focus styles need work, they're too subtle. (...) It could be easier if the focus outline didn't touch the button background. I'll work on that, thanks for the suggestion.
• On the drop-down selects, it has a style for "Active element (previously selected)". What's that for(...)? I saw this behavior in a JS framework and I can't find it right now. I'll update this comment once I find it.

[fuzzbomb]

The error styles for the radio and checkbox:

• These are unusual. I don't recall ever seeing error styles for these anywhere else on web or desktop applications. How are these intended to be used?
• I'm not sure what an error style means for a checked checkbox.... you shouldn't have checked it?
• and for an unchecked checkbox...?
• likewise for the radio buttons, what does the error mean for a checked radio button... we gave you a choice, but you shouldn't have picked this one?
• Will all of the radio buttons in the set get the error style together, one checked and the others unchecked?

Use of colour:

• I can't tell the difference between a checkbox-normal-checked and checkbox-error-checked, except for a colour difference. On it's own that fails WCAG "Use of Color", but it will really depend on how the whole form looks, with the error messages in context too.
• Same for radio-normal-checked vs radio-error-checked, the only difference is colour.
• For unchecked radios and checkbox, i can see that colour isn't the only difference.

I think we need to see the radio and checkbox errors in context on a more realistic form, to know whether the WCAG "Use of Color" is an issue.

[fuzzbomb]

The node edit page shows a grey background inside the URL path settings group. The various focus/selected/error states will need sufficient contrast here too, not just against the white background of the main section. Same for the primary links in the page header region.

[ckrina]

• Errors in radios/checkbox: Yeah, maybe it doesn’t make any sense to have checked radios/checkbox with errors (unchecked with error yes: for example, when you have to “access terms”. Or when a field is mandatory). So I’ve removed the error when checked because I can’t think on any situation it’s going to be needed. FYI I used this as a reference for all states and added the error. I’ve also expanded the examples for errors in the specs on each component on Figma: checkboxes and radios. What do you think of this now?

• Contrast with grey background The background in the sidebar is using #FAFBFD. The focus colour is #004ADC so it shouldn’t be a problem, but I’ll check just in case this and the header. Thanks!

[lauriii]

I think we need to have styles available for error selected radio and checked checkbox. There are some complex use cases where that makes sense, for example when you have inputs that have validation depending on context outside the form input. And also for the checkbox, if there's a limit on how many inputs should be checked, selecting too many inputs probably should trigger that style?

[ckrina]

The focus styles need work, they're too subtle.

@fuzzbomb what do you think about this proposal?

Error messages with and without triangles

We can’t add the error icon on all fields because it would interfere with other elements like the arrow for the select and placing it outside wouldn’t work on small spaces like mobile. The design implies that errors should be inline, so maybe it could be enough to have something else than just the colour?

checked checkboxes with error

Would it be enough in this (strange) situation too to have the inline error?

[fuzzbomb]

@ckrina

Yes, the button focus style is much better. The outline offset introduces an extra thin white line, so the button and focus indicator are now two separate graphic objects. This creates a stronger distinction, especially for the blue button, because there's now a shape change instead of just a size change.

The design implies that errors should be inline, so maybe it could be enough to have something else than just the colour?

But we'd want to be robust enough for sites where Inline Form Errors isn't enabled. We are also introducing Form API properties to allow developers to disable inline form errors on a per-form basis.

[fuzzbomb]

@lauriii

I think we need to have styles available for error selected radio and checked checkbox. There are some complex use cases where that makes sense, for example when you have inputs that have validation depending on context outside the form input.

Yes, maybe. Some examples would help. The only one I can think of right now is the "passwords don't match" error for user accounts. I can't picture any involving radios/checkboxen, but you're probably right that there are some likely situations. But the nature of that error is conveyed in the error message.

And also for the checkbox, if there's a limit on how many inputs should be checked, selecting too many inputs probably should trigger that style?

Seven doesn't do this, and it doesn't suffer from it. The "too many" is explained by the error message, inline or at the top of the form.

One reason to avoid putting a red style on every checkbox, is that it can look too alarming, with seemingly more errors than there actually are. This could be quite unfriendly to users with anxiety disorders and/or perceptual-processing disorders. There isn't a lot published about this though.

As it stands, I don't think there's enough for us to be able to say whether this is good or bad, so let's leave it in place for now. It's worth looking out for in user testing, or feedback from a wider audience. My view is that it's too "loud", and doesn't add much that isn't in the error message.

[saschaeggi]

@fuzzbomb as we moved the issues over to the Drupal issue queue you'll find the new discussion here: https://www.drupal.org/project/claro/issues/3021087 And thanks for your answers!