Accessibility Issue : Semantic elements are used for content that contradicts their meaning and other issues

[Developer-BHN]

Description

Elements appear or function differently than the semantic meaning of those elements.

Semantic elements must be used appropriately so that the content matches the semantic meaning of the element. Mis-using semantic elements can be confusing for assistive technology users. For example, the choice of button vs link has a significant effect on user expectations for assistive technology users: links convey the expectation that the browser will navigate to a different location or page, whereas standard buttons do not. The difference also affects what keys can be used within assistive technologies to navigate between the elements, and which page summaries the element appears in (e.g. buttons don't show up in a list of all links on the page).

Remediation Guidance

Use semantic elements which are appropriate to the content. If it's necessary for an element to behave contrary to its semantic meaning, ensure that ARIA roles and JavaScript behaviours are applied so that the element's behaviour matches user expectations. For example, if a link is used to function as a button, then it should have role="button" as well as additional JS events so that it can be triggered by the Space bar. If a non-interactive element such as <span> is used, it will additionally need tabindex to place it in the Tab order. However, in both cases, a better solution is just to use a <button> element.

Component(s) where this issue occurs
The entire edit image modal has numerous accessibility and functionality issues.

1. Keyboard and other users cannot interact with the cropping, resizing, and positioning functionality. It's only currently operable via mouse or touch
   a. The control tabs for resizing images should be button elements which can be used to adjust the crop frame using the arrow keys
   b. There should be a button element that can be used to move the whole frame around the image using the arrow keys
   c. The button elements should have accessible names using aria-label on the button element

2. The different "editing" controls such as rotate/mirror/color changing + filters are each marked up as an ARIA listbox. For most of these transformations, this is the wrong semantics since they are more complex controls and a "listbox" is functionally the same as a select element, these controls do not function similarly to a select element. These transformations should be evaluated for necessity, and if kept, require (at minimum) the following semantics:
   a. The rotate/flip/mirror transformations should be labeled as simple buttons
   b. The "color" transformations that use the sliders for controlling values should be disclosure widgets with additional markup (such as aria-current="true") that defines when a transform is applied similar to the visual coloration. These transformations should also have a "clear" or "remove transformation" button that removes the transformation from the image
   c. The "image filters" should be marked up as a custom radio group since only 1 filter can be applied at a time.

3. The icons have no accessible names, and the confirm + cancel buttons would benefit from visual labels.

4. The confirm + cancel buttons each come before the tab selector for the different kinds of transformations, but the "confirm" button comes after the tabs visually, and so should be the last part of the content + tab order (Level A failure)

5. The tabs for the different kinds of transformations have invalid tab semantics for the "aria tab" pattern. See the Aria Practicing Guide's Tab Panels for the full description of what the pattern should include. Failures include:
   a. Not using aria-selected="true" on the current selected tab and aria-selected="false" on all other tabs.
   b. Including tab panels inside the "tablist". A tablist can only have "tabs" as children, "tabpanels" need to have a different parent element per the ARIA spec
   c. Tab Panels need an aria-labelledby pointing to their corresponding tab
   d. The tablist needs an aria-label or aria-labelledby that describes the tab component
   e. The list of tabs should come before the list of tab panels in the content + tab order, so it's easier for users to interact with the tabs and peruse the options.

Issue Metadata

Applicable Standards:

4.1.2 Name, Role, Value (Level A)

Content Type:

error

Impacted Populations

Low Vision (Severity: 3)Motor Impaired (Severity: 3)Blind (Severity: 3)Cognitively Impaired (Severity: 3)

Issue Key:

55