Form > Accessibility Audit
Refer to the parent epic description for more information on this effort.
Purpose
Audit the accessibility of a form in GitLab UI.
Note: In GitLab UI, what's listed as the Form component actually contains multiple form elements, some of which have independent audits. For this reason, the following lists document what is in and out of scope here.
In scope:
- Text field
<input type="text">
- Text area
<textarea>
- Labels
<label>
- Select
<select>
- Text descriptions associated with an input
- Help text associated with an input
- States (
invalid
,disabled
)
Out of scope:
Component description
A form is for capturing and submitting user input.
Methods and Tools
Review the initial testing methods in the parent epic. List the testing methods used for your audit below, including any additional testing methods needed for this component that is not listed in the parent epic.
- Testing instance(s) in GitLab UI.
- Using NVDA + Chrome (latest version). See NVDA + Chrome setup for details.
- VoiceOver + Safari (latest version)
- Evaluate all of the component variants and options in GitLab UI
- Visual review for contrast and states
- Semantic and functional review
- Screen reader: VoiceOver + Safari on macOS
- Screen reader: NVDA + Chrome on Windows
- axe DevTools (browser extension)
Audit Criteria
Review the general audit criteria in the parent epic. Add applicable criteria to this section, including any additional criteria needed for this component that is not listed in the parent epic. A check indicates that the audit has been performed, not that it passes.
-
All actions and functionality can be done with a keyboard. -
Links, buttons, and controls have a visible focus state. -
All content is presented in text or with a text equivalent. For example, alt text for SVG, or aria-label
for icons that have meaning or perform actions. -
Changes in a component’s state are announced by a screen reader. For example, changing aria-expanded="false"
toaria-expanded="true"
when an accordion is expanded. -
Color combinations have sufficient contrast. -
Review component specific accessibility guidelines for how attributes and component should behave.
Results
Problem | Solution | Related Issue/MR |
---|---|---|
The visible validation text isn't tied to the input via aria-describedby . |
While the examples infer that the error input is invalid because it's empty, and the other is valid because it's filled in, this visible text may include details necessary to help either remedy or otherwise understand the state. | TBD |
Considerations
The placeholder
text contrast is only 3.64. The Form docs states that placeholder text is, "Only used for extra, non-essential information when the input purpose is still understood in its absence." While the contrast is less than ideal, the other consideration is that increasing the contrast leaves very limited differentiation with an actual input value and could make it appear that an input has been completed, when in fact the value is empty. Given that placeholder text should be non-essential and very limited in use, the decision today is to satisfy at least a 3:1 contrast ratio, but not increase it to 4.5:1 which would inaccurately make the input look filled in.
Completing the audit
After the solutions have been explored and applied, review the completing the audit section in the parent epic. Complete all items prior to closing this issue.
accessibility ~"Category:FE/UX Foundations" component:form