Accessibility of categories modal

[Leeroy-agency]

Description

When selecting some categories in an entry, the ones already selected are harder to read, as the contrast ratio is poor.

Additional info

• Craft version: 3.7.33

[gcamacho079]

@Leeroy-agency thanks for bringing this to our attention! Because these elements are inactive, there’s no hard requirement for them to meet the minimum contrast ratio of 4.5:1 against their background (see Incidental note in Understanding 1.4.3 Contrast: Minimum). However, I do agree it’s a valid usability and a11y issue.

Right now, increasing the text opacity will make it harder to differentiate which items are active versus not, unless we added another visual indicator like text style. I think that might be too subtle of an indicator for most users:

@brandonkelly we’ve discussed refactoring these tables to show the “Selected” column in order to support keyboard and screen reader users. This column would have readonly checkboxes to indicate their selected/disabled states, and editable checkboxes. 

I think at that point, we could increase the opacity of inactive elements to at least 3:1 to make them easier to read. Thoughts?

[brandonkelly]

@gcamacho079 I think it would be a little confusing why the checkboxes aren’t interactive, especially since they are within a modal that is used to select elements.

Maybe we can introduce a new accessibility preference, “Use italics to indicate disabled statuses”, which users could opt into. Then they’d be expecting to see the altered styling, and know what it means.

[gcamacho079]

@brandonkelly I’m all for that extra accessibility feature regarding italic text.



However, it’s still necessary to provide either a checkbox or toggle button for screen reader users. This has the benefit of:


• Providing a natively focusable element. We can’t do that with the table row, as it would need a button/checkbox role (and we can’t do that, as it would override the table row semantics)
• A button/checkbox clearly communicates the selected state to screen reader users



I’ve mocked up an example on Codepen showing discrete toggle buttons in a separate column; updating the text on the selected state lets us be very clear to all users about the selection state.

 Of course, we’d still keep the current select interaction for mouse users. This would just be another method of interacting with the table to benefit additional users. 



I think the question I’m having is - if we update the table with this functionality for all users, would it necessitate an accessibility setting to italicize the inactive row text, or is it clear enough which rows are inactive (since there’s no action button)?

[brandonkelly]

@gcamacho079 I’m definitely fine with adding checkboxes to the existing UI, for choosing which new elements should be added to the selection.

Are you saying that we must also start showing all of the already-selected elements within the modal though? That feels awkward to me because the modal would not be showing all previously-selected elements, depending on which source you have selected, the sort option chosen, any search terms/filters you have applied, etc. If we start listing already-selected elements wouldn’t it be confusing as to why only some of the selected elements (if any) are included in the modal results?

[gcamacho079]

@brandonkelly no, we don't need to list all of already-selected elements inside the modal; I was referring to selected elements that exist as rows inside the applicable table view (based on sort/filter/source).

If an already-selected element is inside the table view, we can just not have a checkbox in its table row.

Just to clarify, when we make this update should we:

1. Darken the text of disabled rows for all users, as the lack of a checkbox will be indication enough that it's inactive?
2. Keep the lower opacity as a default, but allow users to opt-in for the “Use italics to indicate disabled statuses” preference?

[gcamacho079]

This was resolved with #14963