- Quick summary
- Quick checklist
- Provide a good document outline
-
Provide accessible names for screen readers
-
Examples of providing accessible names
- Text inputs with accessible names
- Select inputs with accessible names
- Checkbox inputs with accessible names
- Radio inputs with accessible names
- File inputs with accessible names
- GlToggle components with an accessible names
- GlFormCombobox components with an accessible names
- Images with accessible names
- Buttons and links with descriptive accessible names
- Links styled like buttons
-
Examples of providing accessible names
- Role
- Support keyboard-only use
- Tabindex
- Icons
- Tooltips
- Hiding elements
- When to use ARIA
- Resources
Accessibility
Accessibility is important for users who use screen readers or rely on keyboard-only functionality to ensure they have an equivalent experience to sighted mouse users.
This page contains guidelines we should follow.
Quick summary
Since no ARIA is better than bad ARIA,
review the following recommendations before using aria-*
, role
, and tabindex
.
Use semantic HTML, which has accessibility semantics baked in, and ideally test with
relevant combinations of screen readers and browsers.
In WebAIM’s accessibility analysis of the top million home pages,
they found that “ARIA correlated to higher detectable errors”.
It is likely that misuse of ARIA is a big cause of increased errors,
so when in doubt don’t use aria-*
, role
, and tabindex
and stick with semantic HTML.
Quick checklist
- Text, select, checkbox, radio, file, and toggle inputs have accessible names.
- Buttons, links, and images have descriptive accessible names.
- Icons
-
Non-decorative icons have an
aria-label
. -
Clickable icons are buttons, that is,
<gl-button icon="close" />
is used and not<gl-icon />
. - Icon-only buttons have an
aria-label
.
-
Non-decorative icons have an
- Interactive elements can be accessed with the Tab key and have a visible focus state.
- Elements with tooltips are focusable using the Tab key.
- Are any
role
,tabindex
oraria-*
attributes unnecessary? - Can any
div
orspan
elements be replaced with a more semantic HTML element likep
,button
, ortime
?
Provide a good document outline
Headings are the primary mechanism used by screen reader users to navigate content. Therefore, the structure of headings on a page should make sense, like a good table of contents. We should ensure that:
- There is only one
h1
element on the page. - Heading levels are not skipped.
- Heading levels are nested correctly.
Provide accessible names for screen readers
To provide markup with accessible names, ensure every:
-
input
has an associatedlabel
. -
button
anda
have child text, oraria-label
when child text isn’t present, such as for an icon button with no content. -
img
has analt
attribute. -
fieldset
haslegend
as its first child. -
figure
hasfigcaption
as its first child. -
table
hascaption
as its first child.
Groups of checkboxes and radio inputs should be grouped together in a fieldset
with a legend
.
legend
gives the group of checkboxes and radio inputs a label.
If the label
, child text, or child element is not visually desired,
use .gl-sr-only
to hide the element from everything but screen readers.
Examples of providing accessible names
The following subsections contain examples of markup that render HTML elements with accessible names.
Note that when using GlFormGroup
:
- Passing only a
label
prop renders afieldset
with alegend
containing thelabel
value. - Passing both a
label
and alabel-for
prop renders alabel
that points to the form input with the samelabel-for
ID.
Text inputs with accessible names
When using GlFormGroup
, the label
prop alone does not give the input an accessible name.
The label-for
prop must also be provided to give the input an accessible name.
Text input examples:
<!-- Input with label -->
<gl-form-group :label="__('Issue title')" label-for="issue-title">
<gl-form-input id="issue-title" v-model="title" name="title" />
</gl-form-group>
<!-- Input with hidden label -->
<gl-form-group :label="__('Issue title')" label-for="issue-title" :label-sr-only="true">
<gl-form-input id="issue-title" v-model="title" name="title" />
</gl-form-group>
Textarea examples:
<!-- Textarea with label -->
<gl-form-group :label="__('Issue description')" label-for="issue-description">
<gl-form-textarea id="issue-description" v-model="description" name="description" />
</gl-form-group>
<!-- Textarea with hidden label -->
<gl-form-group :label="__('Issue description')" label-for="issue-description" :label-sr-only="true">
<gl-form-textarea id="issue-description" v-model="description" name="description" />
</gl-form-group>
Alternatively, you can use a plain label
element:
<!-- Input with label using `label` -->
<label for="issue-title">{{ __('Issue title') }}</label>
<gl-form-input id="issue-title" v-model="title" name="title" />
<!-- Input with hidden label using `label` -->
<label for="issue-title" class="gl-sr-only">{{ __('Issue title') }}</label>
<gl-form-input id="issue-title" v-model="title" name="title" />
Select inputs with accessible names
Select input examples:
<!-- Select input with label -->
<gl-form-group :label="__('Issue status')" label-for="issue-status">
<gl-form-select id="issue-status" v-model="status" name="status" :options="options" />
</gl-form-group>
<!-- Select input with hidden label -->
<gl-form-group :label="__('Issue status')" label-for="issue-status" :label-sr-only="true">
<gl-form-select id="issue-status" v-model="status" name="status" :options="options" />
</gl-form-group>
Checkbox inputs with accessible names
Single checkbox:
<!-- Single checkbox with label -->
<gl-form-checkbox v-model="status" name="status" value="task-complete">
{{ __('Task complete') }}
</gl-form-checkbox>
<!-- Single checkbox with hidden label -->
<gl-form-checkbox v-model="status" name="status" value="task-complete">
<span class="gl-sr-only">{{ __('Task complete') }}</span>
</gl-form-checkbox>
Multiple checkboxes:
<!-- Multiple labeled checkboxes grouped within a fieldset -->
<gl-form-group :label="__('Task list')">
<gl-form-checkbox name="task-list" value="task-1">{{ __('Task 1') }}</gl-form-checkbox>
<gl-form-checkbox name="task-list" value="task-2">{{ __('Task 2') }}</gl-form-checkbox>
</gl-form-group>
<!-- Or -->
<gl-form-group :label="__('Task list')">
<gl-form-checkbox-group v-model="selected" :options="options" name="task-list" />
</gl-form-group>
<!-- Multiple labeled checkboxes grouped within a fieldset with hidden legend -->
<gl-form-group :label="__('Task list')" :label-sr-only="true">
<gl-form-checkbox name="task-list" value="task-1">{{ __('Task 1') }}</gl-form-checkbox>
<gl-form-checkbox name="task-list" value="task-2">{{ __('Task 2') }}</gl-form-checkbox>
</gl-form-group>
<!-- Or -->
<gl-form-group :label="__('Task list')" :label-sr-only="true">
<gl-form-checkbox-group v-model="selected" :options="options" name="task-list" />
</gl-form-group>
Radio inputs with accessible names
Single radio input:
<!-- Single radio with a label -->
<gl-form-radio v-model="status" name="status" value="opened">
{{ __('Opened') }}
</gl-form-radio>
<!-- Single radio with a hidden label -->
<gl-form-radio v-model="status" name="status" value="opened">
<span class="gl-sr-only">{{ __('Opened') }}</span>
</gl-form-radio>
Multiple radio inputs:
<!-- Multiple labeled radio inputs grouped within a fieldset -->
<gl-form-group :label="__('Issue status')">
<gl-form-radio name="status" value="opened">{{ __('Opened') }}</gl-form-radio>
<gl-form-radio name="status" value="closed">{{ __('Closed') }}</gl-form-radio>
</gl-form-group>
<!-- Or -->
<gl-form-group :label="__('Issue status')">
<gl-form-radio-group v-model="selected" :options="options" name="status" />
</gl-form-group>
<!-- Multiple labeled radio inputs grouped within a fieldset with hidden legend -->
<gl-form-group :label="__('Issue status')" :label-sr-only="true">
<gl-form-radio name="status" value="opened">{{ __('Opened') }}</gl-form-radio>
<gl-form-radio name="status" value="closed">{{ __('Closed') }}</gl-form-radio>
</gl-form-group>
<!-- Or -->
<gl-form-group :label="__('Issue status')" :label-sr-only="true">
<gl-form-radio-group v-model="selected" :options="options" name="status" />
</gl-form-group>
File inputs with accessible names
File input examples:
<!-- File input with a label -->
<label for="attach-file">{{ __('Attach a file') }}</label>
<input id="attach-file" type="file" name="attach-file" />
<!-- File input with a hidden label -->
<label for="attach-file" class="gl-sr-only">{{ __('Attach a file') }}</label>
<input id="attach-file" type="file" name="attach-file" />
GlToggle components with an accessible names
GlToggle
examples:
<!-- GlToggle with label -->
<gl-toggle v-model="notifications" :label="__('Notifications')" />
<!-- GlToggle with hidden label -->
<gl-toggle v-model="notifications" :label="__('Notifications')" label-position="hidden" />
GlFormCombobox components with an accessible names
GlFormCombobox
examples:
<!-- GlFormCombobox with label -->
<gl-form-combobox :label-text="__('Key')" :token-list="$options.tokenList" />
Images with accessible names
Image examples:
<img :src="imagePath" :alt="__('A description of the image')" />
<!-- SVGs implicitly have a graphics role so if it is semantically an image we should apply `role="img"` -->
<svg role="img" :alt="__('A description of the image')" />
<!-- A decorative image, hidden from screen readers -->
<img :src="imagePath" :alt="" />
Buttons and links with descriptive accessible names
Buttons and links should have accessible names that are descriptive enough to be understood in isolation.
<!-- bad -->
<gl-button @click="handleClick">{{ __('Submit') }}</gl-button>
<gl-link :href="url">{{ __('page') }}</gl-link>
<!-- good -->
<gl-button @click="handleClick">{{ __('Submit review') }}</gl-button>
<gl-link :href="url">{{ __("GitLab's accessibility page") }}</gl-link>
Links styled like buttons
Links can be styled like buttons using GlButton
.
<gl-button :href="url">{{ __('Link styled as a button') }}</gl-button>
Role
In general, avoid using role
.
Use semantic HTML elements that implicitly have a role
instead.
Bad | Good |
---|---|
<div role="button">
| <button>
|
<div role="img">
| <img>
|
<div role="link">
| <a>
|
<div role="header">
|
<h1> to <h6>
|
<div role="textbox">
|
<input> or <textarea>
|
<div role="article">
| <article>
|
<div role="list">
|
<ol> or <ul>
|
<div role="listitem">
| <li>
|
<div role="table">
| <table>
|
<div role="rowgroup">
|
<thead> , <tbody> , or <tfoot>
|
<div role="row">
| <tr>
|
<div role="columnheader">
| <th>
|
<div role="cell">
| <td>
|
Support keyboard-only use
Keyboard users rely on focus outlines to understand where they are on the page. Therefore, if an element is interactive you must ensure:
- It can receive keyboard focus.
- It has a visible focus state.
Use semantic HTML, such as a
and button
, which provides these behaviours by default.
Keep in mind that:
- Tab and Shift-Tab should only move between interactive elements, not static content.
- When you add
:hover
styles, in most cases you should add:focus
styles too so that the styling is applied for both mouse and keyboard users. - If you remove an interactive element’s
outline
, make sure you maintain visual focus state in another way such as withbox-shadow
.
See the Pajamas Keyboard-only page for more detail.
Tabindex
Prefer no tabindex
to using tabindex
, since:
- Using semantic HTML such as
button
implicitly providestabindex="0"
. - Tabbing order should match the visual reading order and positive
tabindex
s interfere with this.
Avoid using tabindex="0"
to make an element interactive
Use interactive elements instead of div
and span
tags.
For example:
- If the element should be clickable, use a
button
. - If the element should be text editable, use an
input
ortextarea
.
Once the markup is semantically complete, use CSS to update it to its desired visual state.
<!-- bad -->
<div role="button" tabindex="0" @click="expand">Expand</div>
<!-- good -->
<gl-button class="gl-p-0!" category="tertiary" @click="expand">Expand</gl-button>
Do not use tabindex="0"
on interactive elements
Interactive elements are already tab accessible so adding tabindex
is redundant.
<!-- bad -->
<gl-link href="help" tabindex="0">Help</gl-link>
<gl-button tabindex="0">Submit</gl-button>
<!-- good -->
<gl-link href="help">Help</gl-link>
<gl-button>Submit</gl-button>
Do not use tabindex="0"
on elements for screen readers to read
Screen readers can read text that is not tab accessible.
The use of tabindex="0"
is unnecessary and can cause problems,
as screen reader users then expect to be able to interact with it.
<!-- bad -->
<p tabindex="0" :aria-label="message">{{ message }}</p>
<!-- good -->
<p>{{ message }}</p>
Do not use a positive tabindex
Always avoid using tabindex="1"
or greater.
Icons
Icons can be split into three different types:
- Icons that are decorative
- Icons that convey meaning
- Icons that are clickable
Icons that are decorative
Icons are decorative when there’s no loss of information to the user when they are removed from the UI.
As the majority of icons within GitLab are decorative, GlIcon
automatically hides its rendered icons from screen readers.
Therefore, you do not need to add aria-hidden="true"
to GlIcon
, as this is redundant.
<!-- unnecessary — gl-icon hides icons from screen readers by default -->
<gl-icon name="rocket" aria-hidden="true" />`
<!-- good -->
<gl-icon name="rocket" />`
Icons that convey information
Icons convey information if there is loss of information to the user when they are removed from the UI.
An example is a confidential icon that conveys the issue is confidential, and does not have the text “Confidential” next to it.
Icons that convey information must have an accessible name so that the information is conveyed to screen reader users too.
<!-- bad -->
<gl-icon name="eye-slash" />`
<!-- good -->
<gl-icon name="eye-slash" :aria-label="__('Confidential issue')" />`
Icons that are clickable
Icons that are clickable are semantically buttons, so they should be rendered as buttons, with an accessible name.
<!-- bad -->
<gl-icon name="close" :aria-label="__('Close')" @click="handleClick" />
<!-- good -->
<gl-button icon="close" category="tertiary" :aria-label="__('Close')" @click="handleClick" />
Tooltips
When adding tooltips, we must ensure that the element with the tooltip can receive focus so keyboard users can see the tooltip.
If the element is a static one, such as an icon, we can enclose it in a button, which already is
focusable, so we don’t have to add tabindex=0
to the icon.
The following code snippet is a good example of an icon with a tooltip.
- It is automatically focusable, as it is a button.
- It is given an accessible name with
aria-label
, as it is a button with no text. - We can use the
gl-hover-bg-transparent!
class if we don’t want the button’s background to become gray on hover. - We can use the
gl-p-0!
class to remove the button padding, if needed.
<gl-button
v-gl-tooltip
class="gl-hover-bg-transparent! gl-p-0!"
icon="warning"
category="tertiary"
:title="tooltipText"
:aria-label="__('Warning')"
/>
Hiding elements
Use the following table to hide elements from users, when appropriate.
Hide from sighted users | Hide from screen readers | Hide from both sighted and screen reader users |
---|---|---|
.gl-sr-only
| aria-hidden="true"
|
display: none , visibility: hidden , or hidden attribute
|
Hide decorative images from screen readers
To reduce noise for screen reader users, hide decorative images using alt=""
.
If the image is not an img
element, such as an inline SVG, you can hide it by adding both role="img"
and alt=""
.
gl-icon
components automatically hide their icons from screen readers so aria-hidden="true"
is
unnecessary when using gl-icon
.
<!-- good - decorative images hidden from screen readers -->
<img src="decorative.jpg" alt="">
<svg role="img" alt="" />
<gl-icon name="epic" />
When to use ARIA
No ARIA is required when using semantic HTML, because it already incorporates accessibility.
However, there are some UI patterns that do not have semantic HTML equivalents. General examples of these are dialogs (modals) and tabs. GitLab-specific examples are assignee and label dropdowns. Building such widgets require ARIA to make them understandable to screen readers. Proper research and testing should be done to ensure compliance with WCAG.
Resources
Viewing the browser accessibility tree
Browser extensions
We have two options for Web accessibility testing:
Other links
- The A11Y Project is a good resource for accessibility
- Awesome Accessibility is a compilation of accessibility-related material