Accessibility

Lone Wolf UI Kit - Accessibility Requirements

Before you begin...

Accessibility makes the experience of all users better – not just those who depend on assistive technologies.

When creating web apps and websites, we should be striving to provide our users with a product that is intuitive, understandable and easy to use. While it is difficult to esitmate exact numbers of people who depend on assistive technologies, we can get an idea from a Microsoft 2003 survey that estimated that:

  • approximately 1 in 4 users have a visual difficulty or imparement
  • approximately 1 in 4 have dexterity difficulty or imparement
  • approximately 1 in 5 have a hearing difficulty or imparement

Whether it's due to a disability or the technology in use, we should expect that there will be users accessing our products who:

  • will need an additional distinguisher to tell different colours apart
  • will need high contrast between colours and text
  • will need to navigate without a mouse
  • will need a way to read audio or hear written text
  • will need to zoom in on text or imagery
  • will need to use their voice to control their computer

The requirements outlined in this document have been included to make the experience better for all users, no matter how they are using our products. If elements are used as described in our UI kit, LW-universal.js already handles most of the dynamically changing functionality. If you ever run into an instance where implementation need to be customized, accessibility requirements have been outlined for each element.

General Principles To Make Implementing Accessibility Easier For You

  • All pages must be written in semantic HTML, where the meaning of the content will not change if a stylesheet is not present.
  • All pages must be fully navigable by keyboard and readable by screen readers in a sequential manner.
  • There must be a way to skip over large blocks of content that repeats on all pages (such as a "Skip to Content" link).
  • Instructions and errors must be clearly described and must not be indicated only by colour, shape, visual location, orientation, or sound.
  • There must be a way to control any media content, and all media should include an alternate to communicate the information.

Note! Screen reader examples given have been provided through the use of Chrome Vox. Not every screen reader will announce items in the exact same way, and not every screen reader will recognize all of the same elements and attributes. The requirements provided, however, are industry standard to be as inclusive as possible for all screen readers.

Buttons

Expected Interaction

Keyboard Access

Keyboard users should be able to Tab to all active buttons. Users should be able to press the Spacebar or Enter key to activate the button.

Any links that look like buttons are required to function like buttons.

info Exception Note! If a button is disabled, the user should not be able to activate it by Enter or Spacebar.

Screen Reader Access

A screen reader will announce the text visible in the button, as well as the role of the element. For the below example, Chrome Vox will announce, "Default Button, Button".

Accessibility requirements

  • role="button" is required for any a that looks like a button.
  • aria-label="REPLACE ME" is required for buttons that only include an icon. The property should be the text the screen reader should read instead on the icon.
  • All elements are required to function as described in their individual sections (see Icons).

Button Groups

Expected Interaction

Keyboard Access

Keyboard users should be able to Tab through all buttons included in a button group.

Screen Reader Access

A screen reader will announce the label of the button group. When an individual button is selected, the screen reader will function as outlined for Buttons.

For the below example, Chrome Vox will announce "Text Format Buttons" for the full group, then announce each individual aria-label attribute ("Left Align Text", "Center Text", "Right Align Text" and "Justify Text" respectively).

Accessibility requirements

  • All buttons in the group are required to be logically related to each other.
  • role="group" is required on .btn-group.
  • aria-label="REPLACE ME" is required on .btn-group. The property should be descriptive of the group of buttons.
  • aria-label="REPLACE ME" is required on .btn if it only includes an icon. The property should be the text the screen reader should read instead on the icon.

Responsive Utilities

Keyboard Access

Users should not be able to access hidden areas by keyboard.

Screen Reader Access

Screen readers should not able able to read hidden content.

Icons

Expected Interaction

Screen Reader Access

Icons should be hidden from screen readers, with an additional label added to the element wrapping the icon.

Without proper attributes, the below icons would be announced by Chrome Vox as, "more underscore horiz" and "assignment underscore ind." With the proper attributes added, Chrome Vox no longer reads them.

Accessibility requirements

  • aria-hidden="true" is required on .material-icons.
  • aria-label="REPLACE ME" is required on elements where the icon is the only means of communicating a message to users (for example, Buttons).

Cards

Expected Interaction

Keyboard Access

Users should be able to Tab into any button, link, or interactive element within any card.

Screen Reader Access

Screen readers should be able to read all content included in a card – this includes the title, subtitle, the descriptive alt text for an image, and button labels.

Chrome Vox would read the example to the right as, "Card title. Support card subtitle. Card image cap. Card link, internal link. Card link, internal link."

Card title

Support card subtitle
Card image cap
Card link Card link

Accessibility requirements

  • All images are required to have a descriptive alt tag.
  • All elements are required to function as described in their individual sections (see Buttons, Icons).

Depending on the purpose of the implemented card, one of the following roles may be required:

  • article - required when the card is an independent part of a document, page or site.
  • complimentary - required when the card relates to the main content, but is still meaningful without the main content.
  • definition - required when the card is used to define of a term or concept.
  • note - required when the card is ancillary to the main content.

Tables

Expected Interaction

Keyboard Access

Keyboard users shouuld be able to Tab through any interactive content in the table. Any links should be able to be activated by Enter; buttons should be able to be activated by Enter or Spacebar.

Screen Reader Access

Screen readers should be able to read all content in tables. Any cell that doesn't have full text in it (such as the '#' in this example) needs alternate text. All buttons are required to be readable by a screen reader.

For the below example, Chrome Vox will announce, "Table. Ranking" (the screen reader only text in the first cell) when entering this table, and will read each table cell content as the table is being navigated through.

Ranking Name Title Since Total Sales Actions
1 Helen K. Pompeii Sales Representative 2013 $225,810,000
2 Michelle Brown Broker 2012 $221,295,000
3 Franky Ocean Sales Representative 2010 $198,332,000

Accessibility requirements

  • scope="col" or scope="row" is required for each column and row th.
  • span class="sr-only" is required if there is any text that won't be intuitive to people using assisstive technology.
  • span aria-hidden="true" is required to hide any non-intuitive text from the screen reader from reading it.
  • All elements are required to function as described in their individual sections (see Buttons and Icons).

Sorting Table With Filters

Expected Interaction

Keyboard Access

Users should be able to tab through each table header and each input field. Hitting enter while focused on a cell in the table header should sort the table in either ascending or descending order by the column focused on.

After tabbing though the header, users should then be able to tab through all interactive elements within the table body. After tabbing through the table body, users should be able to tab through any input or interactive element within the footer.

Any inputs should be fully editable by keyboard.

Activating a checkbox in the table header by hitting the spacebar or the enter key should automatically check (or uncheck) all checkboxes in the same column of the table.

Screen Reader Access

When focused on one of the table headers, the screen reader should read the visible text, as well as any additional hint text to let the user know that the cell is interactive.

For the below example, Chrome Vox will announce, "Grid. First Name. No sort applied. Activate to apply an ascending sort. Column header."

When focused on one of the input fields, the screen reader should announce the title of the column, give a hint as to the text that can be entered and indicate that the field is editable.

For the below example, Chrome Vox will announce, "Search First Name with hint 'Edit Text'. Search entry."

The screen reader should be able to read all content located within the table, including a hidden label to indicate that the checkbox selects the entire row.

Within the pagination of the table, the screen reader should be able to read what the button group is titled, the button labels, and the number of results in both the filtered and unfiltered table.

For the below example, Chrome Vox will announce, "Data navigation. Group. First page, button disabled. Previous page, button disabled. One to four of four results. There are four results when unfiltered. Next page, button disabled. Last page, button disabled."

Lastly, any additional fields in the footer should be readable by screen readers as well.

First Name Last Name Gender English Japanese Calculus
GillianWongfemale807092
StacySinatrafemale9088100
StephenGillmale859580
GordonMcAllenmale6055100

Accessibility Requirements

  • When thead is utilized, it is required before tbody; when tfoot is utilized, it is required after tbody
  • aria-label="REPLACE ME" is required on all checkboxes, pagination buttons, column headers, input text boxes and on .btn-group
  • tabindex="0" is required on all column headers that a user can use to sort with
  • aria-disabled="false" is required on all column headers that a user can sort with. If the user cannot use a column to sort, this attribute is required to change to true
  • aria-sort="no" is required on all column headers that are sortable but not currently active. This attribute is required to change to ascending or descending when the column is being used to sort the table
  • aria-live="polite" is required on the tbody
  • aria-relevant="all" is required on the tbody
  • All elements are required to function as described in their individual sections (see Buttons, Button Groups, Icons, Checkboxes, Selects and Multiselects, and Inputs).

Alerts

Expected Interaction

Keyboard Access

The close button on any alert should be accessible to keyboard users. When a user closes an alert, the keyboard will move focus to the following element.

Screen Reader Access

When there is an alert on a page, a screen reader will read this before any other content on the page. For the below example on page load, Chrome Vox will read the title of the page and then immediately say, "Error Alert. Alert. Error Alert: You've hit an error, please check your information and try again." This indicates the title of the element, what the element is, and the text included in the element.

Accessibility requirements

  • role="alert" is required to tell screen readers that this is an important dialog and to read it first on page load.
  • aria-label="REPLACE ME" is required on .alert. This property should be what a screen reader should label this area.
  • aria-describedby="REPLACE ME" is required on .alert. This property should be the id of the span wrapping the alert message.
  • id="REPLACE ME" is required on the span around the alert message.
  • aria-hidden="true" is required on .alert-icon to hide the icon included in the alert from screen readers.
  • aria-label="Close" is required on .close to tell screen readers that this button will close the alert.

Note! Currently, alerts appear on page load and page refresh. If one needs to be added in dynamically, using the provided code and accessibility requirements should still cause the screen reader to read the alert as soon as it is finished communicating what else it is currently saying. Dependent on where the alert appears, you may be required to scroll the page so the alert is in the viewport.

Inputs

Expected Interaction

Keyboard Access

Users should be able to Tab into and out of any form input areas in a logical manner. For example, if there are three input elements on one line, the user should be able to Tab from the left input, into the middle input, then into the right input.

When focused on an input, the user should be able to type into the field.

Screen Reader Access

Screen readers should indicate all form field labels. Some screen readers will also read the placeholder text.

For example, for the first two examples below, Chrome Vox would state, "Default with label, with hint Placeholder text. Edit text." For the third example, Chrome Vox would state, "Default with label. Edit text."

When a user starts typing in the input, the screen reader should speak out the letters as they are entered into the input area.

Accessibility requirements

  • for="REPLACE ME" is required on corresponding label. The property should refer to the input element's id.
  • aria-label="REPLACE ME" is required on any input element without a corresponding label. The property should include descriptive text for the element.
  • aria-hidden="true" is required for any icons.

Note! Placeholder text is not recognzed by all screen readers, and should only be used to indicate helpful hints as to the content required (for example, "you@email.com" would be acceptable placeholder text for email inputs).

Selects & Multi-Selects

Expected Interaction

Keyboard Access

Keyboard users should be able to Tab in and out of all select and multi-select areas.

When focused into a select area, hitting the Spacebar will open the select options. The user will be able to use the Up and Down arrows to navigate through the options. Hitting the Escape key will close the list of select options. Hitting the Spacebar again, or hitting the Enter key, will close and select the current option.

When the Multi-Select is focused on, a user can navigate the list of options by using the Up and Down arrows. Consecutive items can be selected by pressing Spacebar with either the Up or Down arrow. Pressing Ctrl A selects all options. If supported by the browser, pressing Ctrl Up or Ctrl Down arrow will allow the user to navigate through the list without selecting an option; a user can select an element by pressing the Space button.

Screen Reader Access

When a user focuses on a select box, the screen reader should read out the label of the select box. If it is a basic select, the option that is selected by default will be read. If it's a mult-select, the screen reader should indicate this; if any options are selected in the multi-select, the screen reader should also indicate this. Lastly, it should indicate that this is a combo box or select, as well as how many items are in the select.

For the below example, Chrome Vox will say, "Basic Select. What is your favourite type of cat? Combo box. One of six."

For the below example, Chrome Vox will say, "Multi-Select. Combo box. Multi-select. Zero of seven." When one item is selected, Chrome Vox will say, "Bourbon Vanilla. Multi-select. Four of seven. Bourbon Vanilla." When multiple items are selected, Chrome Vox will say, "Chocolate Mint to Tears of My Enemies. Listbox. Multi-select. Selected three items."

Accessibility requirements

  • for="REPLACE ME" is required on corresponding label. The property should refer to the input element's id.
  • aria-label="REPLACE ME" is required on any select element without a corresponding label. The property should include descriptive text for the element.
  • aria-multiselectable="true" is required on select if multiple items can be selected.

Selectize.js

Expected Interaction

Keyboard Access

A user should be able to Tab into and out of each combobox.

When in a combobox, a user should be able to use the Up and Down keys to scroll through the list of options presented. Hitting Enter will select the highlighted option and close the combobox field.

The Backspace key will allow the user to remove all text in the combobox. At any point in time, the user can begin typing text in order to filter the results in the options.

If a user has typed in text into the field and there isn't a current object existing with the same text, they should be able to create that option but pressing the Up arrow until they reach they "Add" option and hitting the Enter key.

The multi-select functions in the same way, except it allows users to enter more than one item into each multi-select.

Screen Reader Access

When a user focuses on an combobox, a screen reader should announce the role of the element (listbox), any content that is currently included or active in the element. For the below option, Chrome Vox will say, "Coyote. Listbox."

When a user focuses on the label of the element, the screen reader may currently say a different thing, due to a bug with the script. See note below.

When using selectize as a multi tag input, the element will interact with screen readers slightly differently. It should list input instead of listbox, and indicate that text can be edited. When clicking inside the text box in the below example, Chrome Vox will say, "Combobox. Edit text."

Exception Note! At this point in time, navigating the dropped down list of options does not trigger the screen reader to indicate what day they are on. As the input field itself is still fully editable and the dropdown list isn't the only way to input information into the field, the field is still accessible to those using screen readers.

Exception Note! There is a documented bug that the label does not associate with the selectize script. (Clicking on the label doesn't make the selectize input active.) Labelling each form element is still required as it will be something that is added to the script in the future.

Accessibility requirements

  • role="option" is required for .selectize-dropdown-content div (generated for selectize-dropdown).
  • for="REPLACE ME" is required on corresponding label – this needs to reflect the id generated for .selectize-input input.
  • aria-label="REPLACE ME" is required on any input without a corresponding label and for each div in .selectize-dropdown. This property should reflect what the screen reader should say to users.
  • role="application" is required on .selectize-control to tell screen readers that this area functions differently than a traditional webpage.
  • role="combobox" is required on .selectize-input input to tell screen readers that users can type in to select an option add a new item.
  • aria-owns="REPLACE ME" is required on .selectize-input input. This property refers to the id of the .selectize-dropdown.
  • id="REPLACE ME" is required on .selectize-dropdown.
  • id="REPLACE ME" is required on .selectize-input input.
  • aria-haspopup="true" is required on .selectize-input input.
  • aria-autocomplete="list" is required on .selectize-input input to tell screen readers that a list of suggestions will appear when a user begins typing.

Datepicker

Expected Interaction

Keyboard Access

When a keyboard user brings focus to the date input, a calendar will automatically appear above or below the field. The Up arrow will move the selected date up exactly one week; the Down arrow will move the selected date down exactly one week. The Left arrow will move the selected date back exactly one day; the Right arrow wil move the selected date forward exactly one day.

Shift + Up/Left will move back one month; Shift + Down/Right will move forward one month. Ctrl + Up/Left will move back one year; Ctrl + Down/Right will move forward one year.

The Enter key selects the date that has been highlighted. Escape will close the calendar view.

Screen Reader Access

When a user enters the input field, the screen reader should announce the field's name, any placeholder text, any pre-existing values, and that a popup has been expanded.

For example, when a user enters the below input field below Chrome Vox will say, "Select a date. Oh three slash twelve slash twenty sixteen. Edit text. Expanded."

Exception Note! At this point in time, navigating the popped up calendar by the keyboard does not trigger the screen reader to indicate what day they are on. As the input field itself is still fully editable and the calendar isn't the only way to input information into the field, the field is still accessible to those using screen readers.

Accessibility requirements

  • for="REPLACE ME" is required on corresponding label. The property should refer to the id of the element it labels.
  • aria-label="REPLACE ME" is required for any input elements that do not have a corresponding label. The property should include what the screen reader should title the element.
  • aria-expanded="false" is required on .datepicker when the input is not focused on and the calendar isn't open. When the calendar is open, this state is required to change to true.
  • aria-haspop="true" is required.
  • aria-hidden="true" is required for any icons.

Textarea

Expected Interaction

Keyboard Access

Keyboard users should be able to Tab into and out of all textareas. When focused on a textarea, users should be able to type into the field.

Screen Reader Access

The screen reader should pronounce the textarea's label and indicate that it's a textarea.

For example, with the below textarea, Chrome Vox would say, "Screen reader label text for textarea. Textarea."

Note! Placeholder text is not recognzed by all screen readers, and should only be used to indicate helpful hints as to the content required.

Accessibility requirements

  • for="REPLACE ME" is required for corresponding label. This property should include the id of the element it belongs to.
  • aria-label="REPLACE ME" is required for any textarea elements that do not have a corresponding label. This property should indicate what the screen reader should call this element.
  • aria-hidden="true" is required for any icons.

Checkboxes

Expected Interaction

Keyboard Access

All checkboxes should be able to be navigated into and out of by using the Tab button. When a checkbox is focused on, hitting the Spacebar will check or uncheck the checkbox.

Screen Reader Access

Screen readers should read the label of the checkbox, indicate that the element is a checkbox and whether the checkbox is checked or unchecked.

For example, Chrome Vox will read the below label as, "Check and uncheck this label. Checkbox. Unchecked."

Accessibility requirements

  • label is required to be wrapped around input.

Checkbox Toggle

Expected Interaction

Keyboard Access

Keyboard users should be able to Tab into and out of all checkbox toggles. Pressing Spacebar will toggle and untoggle the element.

Screen Reader Access

Screen readers should announce the label of the toggle, as well as whether it is checked or unchecked.

For the below example, Chrome Vox will say, "Receive Notifications. Checkbox. Checked."

Accessibility requirements

  • aria-label="REPLACE ME" is required on the input as not all screen readers associate the two labels for this element with the checkbox. The property should indicate what the screen reader should describe this input as.

Radios and Radio Button Groups

Expected Interaction

Keyboard Access

Keyboard users should be able to Tab into the first radio button in a group of radio buttons; pressing Tab a second time will exit the group of radio buttons.

The Spacebar will check the radio button the user is focused on.

The Up or Left arrows will select and check the previous radio button; the Down or Right arrows will select and check the next radio button.

Screen Reader Access

Screen readers should read the label of the radio button, announce that this is a radio button and whether it is checked or unchecked.

For the below example, Chrome Vox will state, "Toggle this custom radio. Radio button. Unselected."

Toggle inputs can be stacked

Accessibility requirements

  • label is required to be wrapped around input.
  • All elements are required to function as described in their individual sections (see Icons and Button Groups).

Product Platform Navbar

Expected Interaction

Keyboard Access

Users should be able to Tab into any button, link, or interactive element within the product platform navbar.

Any side panel or menu can be opened by pressing the Enter or Spacebar when focused on a button. The focus will remain on the button. Pressing the Down arrow will bring the focus into the menu or panel. Pressing the Escape button at any point when the side menu or panel is open will close the menu or panel.

Inside each panel, the Tab button can be used to navigate between links and form elements.

The tabs in the side panels will function as described for Navs.

Screen Reader Access

When focused on any of the buttons in the product platform navbar, the screen reader should announce it's name, say that it's a button with a popup, and say whether it's expanded or collapsed.

For example, Chrome Vox announces the Menu button below as, "Menu, Popup Button, Collapsed, Menu."

When entering a menu or panel, the screen reader should be notified of the item they are now focused on. For example, Chrome Vox announces entering the main menu as, "Navigation list with 8 items. Messages. Two. Link list item."

Accessibility requirements

  • aria-haspopup="true" is required for buttons with a modal or slideout menu/panel
  • aria-expanded="false" is required for buttons with a modal or slideout menu/panel. When a menu/panel is open and visible, this state is required to change to true.
  • tabindex="-1" is required for all links, buttons, input and other interactive elements on hidden panels. When the panel/menu is visible, this is required to change to 0.
  • All elements are required to function as described in their individual sections (see Navs, Buttons, Icons, Checkboxes, Inputs, Modals, and Selects).

Actionbar

Expected Interaction

Keyboard Access

Keyboard users should have the ability to Tab through all buttons, links and dropdowns included in the Actionbar.

All links should be activated by Enter, and all buttons should be activated by Spacebar or Enter.

Screen Reader Access

When focused on the full Actionbar, the screen reader should indicate that this element has a navigation role, as well as the page title. For example, when focusing on the Actionbar, Chrome Vox will announce that this is "Dashboard. Navigation."

Each additional element should be listed as a menu item, with the title of the link and whether it is a dropdown.

Dashboard help_outline

Accessibility requirements

  • role="navigation" is required on .actionbar.
  • aria-labelledby="REPLACE ME" is required on .actionbar. The property should refer to the id of the heading in the actionbar.
  • role="menuitem" is required for all menu links.
  • aria-haspopup="true" on all top-level menu items with a dropdown; aria-haspopup="true" is required on all top-level menu items without a dropdown.
  • All elements are required to function as described in their individual sections (see Modals, Dropdowns, Buttons and Icons).

Smooth Scroll

Expected Interaction

Keyboard Access

Keyboard users should be able to initialize the smooth scrolling with either the Enter or Spacebar keys.

Screen Reader Access

The screen reader should announce that this is a button, as well as what the text of the button is. For example, Chrome Vox will state, "Oh, Scroll Me. Button." When the button has been activated, the screen reader should then begin speaking the text that the browser has scrolled to.

Oh, Scroll Me

Nice Scrollbars

Expected Interaction

Keyboard Access

When a user is focused in the scrollable area, the following keys can be used to navigate: the Arrow keys scroll through slowly, the Page Up and Page Down keys scroll thought more area, the Home button scrolls to the top of the content, and the End button scrolls to the bottom of the content.

Screen Reader Access

When a user focuses on the scrollable area, the screen reader will announce the label of the scrollable area, and then can be used to navigate the area in the same way that is used to navigate the rest of the document.

SlimScroll.js in action!

width - Width in pixels of the visible scroll area. Stretch-to-parent if not set. Default: none

height - Height in pixels of the visible scroll area. Also supports auto to set the height to same as parent container. Default: 250px

size - Width in pixels of the scrollbar. Default: 7px

position - left or right. Sets the position of the scrollbar. Default: right

alwaysVisible - Disables scrollbar hide. Default: false

distance - Distance in pixels from the edge of the parent element where scrollbar should appear. It is used together with position property. Default:1px

start - top or bottom or $(selector) - defines initial position of the scrollbar. When set to bottom it automatically scrolls to the bottom of the scrollable container. When HTML element is passed, slimScroll defaults to offsetTop of this element. Default: top.

wheelStep - Integer value for mouse wheel delta. Default: 20

railVisible - Enables scrollbar rail. Default: false

railColor - Sets scrollbar rail color, Default: #333333

railOpacity - Sets scrollbar rail opacity. Default: 0.2

allowPageScroll - Checks if mouse wheel should scroll page when bar reaches top or bottom of the container. When set to true is scrolls the page.Default: false

scrollTo - Jumps to the specified scroll value. Can be called on any element with slimScroll already enabled. Example: $(element).slimScroll({ scrollTo: '50px' });

scrollBy - Increases/decreases current scroll value by specified amount (positive or negative). Can be called on any element with slimScroll already enabled. Example: $(element).slimScroll({ scrollBy: '60px' });

disableFadeOut - Disables scrollbar auto fade. When set to true scrollbar doesn't disappear after some time when mouse is over the slimscroll div.Default: false

touchScrollStep - Allows to set different sensitivity for touch scroll events. Negative number inverts scroll direction.Default: 200

Accessibility requirements

  • role="region" is required on .scrollable
  • aria-label="REPLACE ME" is required on .scrollable. The property tells the screen reader what to title this scrollable area
  • tabindex="0" is required on .scrollable to allow keyboard users to focus on the area and scroll through it.