WHAT IS WEB ACCESSIBILITY?
Web accessibility refers to web pages that are designed and developed to be inclusive for all users. Whether users can see and interact with a website via the screen or through the use of a screen reader, web accessibility provides equal access to information and functionality.
Why does accessibility matter to us?
More than 39 Million people in the U.S. [12.6%] live with a disability according to the 2013 United States Census Bureau report.
- 75% of people with disabilities use computers today*
- More than 66% of people with disabilities use some form of accessible technology*
*Microsoft Study conducted by Forrester Research, Inc.
Alkami and Accessibility
At Alkami our mission is to ensure that the design, implementation, and maintenance of our online banking software is accessible to individuals with a range of disabilities. This means Alkami, as a company, is committed to integrating accommodations for:
- Users of screen readers
- Users with low or impaired vision
- Users who experience manual dexterity issues
In the absence of specific regulatory guidance, Alkami has determined to adopt the standards in the WCAG 2.0 Level AA guidelines for our customer-facing online banking desktop interfaces and for mobile applications adopt W3C mobile accessibility guidelines. BBC Standards and Guidelines for mobile accessibility are also being used as a best practices reference.
Iris and Accessibility
Alkami and the Iris team view the Iris Design System as the foundation for Alkami’s scalable solution to accessibility. Iris is doing this in the following ways:
- Re-usable components improve accessibility and consistency when building products
- Iris component code includes accessible markup
- Additional guidance and training to those using Iris components ensures accessibility best practices are being applied in coordination with the use of Iris components
All of our components are made to be accessible by everyone. They meet the latest accessibility standards, as we strive to build a unified experience for both visual display and screen reader users. In each component’s documentation, we’ve included an accessibility guide on what to pay attention to when implementing a component and on what accessibility features are included in the component itself.
The Iris Team is passionate about designing code that is accessible to everyone and that elevates the Alkami experience.
If you’d like to give us feedback about Iris and accessibility, send an email to firstname.lastname@example.org or stop by if you are in the Alkami office. We are always happy to talk about the system and opportunities to improve it!
HTML5 natively provides a great number of new semantic elements and attributes, most of which are supported by the majority of screen readers in use today. That means that just by leveraging HTML5 on our pages, we get some accessibility right away. Let's take a look at what HTML5 can provide in the sections below.
Setting the right Doctype is a great way to get started.
Landmarks and Roles
Landmarks and roles give deeper information to screen readers on how a page is structured and provides a map for how to navigate designated sections. Developers can also define bypass blocks and shortcuts that allow screen reader users to skip over repetitive elements on a page (for example: widget navigation). All of these make it easier to locate content in our widgets while providing a great experience for everyone.
Here is a good example page of how it works, with suggestions on markup: Landmarks Example.
Here's a quick summary of this example: Both the HTML5 elements and Accessible Rich Internet Applications (ARIA) roles should be used because each is supported differently, based on the screen reader in use. For instance, the iOS screen reader VoiceOver, doesn't identify
<footer> as a landmark but it does describe
<header> as a banner, and
<aside> as complementary – which are their ARIA role equivalents. The page shows that both
<main> are not treated by landmarks for VoiceOver, but the version in use when creating this page did. It is best to use VoiceOver or another screen reader on the page to see how it actually behaves.
<main> element is used to show content that is specifically related to the central topic of the document. In the example below, this is the
<main id="primary_widget_content" aria-label="Content"> ... ... ... </main>
- Only one (1)
<main>element is allowed per page.
- Always include aria-label="Content" to ensure screen readers announce this as "Main content".
Header and Banner
<header> element is used for the header of a document or section. The header typically has a child which is a heading (H1 – H6) for the document or section that it lives in, but it can also contain a nav, search field, or other information that makes sense from a contextual standpoint.
The banner attribute gives an additional piece of information to screen readers to indicate that the content it refers to is a piece of consistent content across the site that doesn't need to be read on every page and can be quickly skipped over.
<header role="banner" aria-label="Page"> <!-- Custom FI markup --> ... ... ... </header>
You can use the
<header> element multiple times for a document or section. The only limitations are that the header cannot be a descendant of another
<address> element. The ARIA role="banner" attribute is generally used to indicate site-oriented content rather than page-specific content.
Here are a few things to keep in mind about headers:
<header>element should only be used as a container for introductory content.
- The use of multiple
<header>elements on any given page is permissible and preferable for accessibility purposes.
- Conversely, there can be only one role="banner" and it must be used on a
- Always use an aria-label attribute that is concise and descriptive on the role="banner" element (for example: "Main" or "Page").
Headings (H1 - H6)
Headings are the
<h6> elements used to highlight the heading of a page or section. The screen reader uses this element to make it easy to skip through the headings or sections of a page to search for the ones the user is interested in. Therefore, it's important that when you think about using a heading element, you consider whether or not it applies to the situation you are working on. A heading should be used for the text that introduces a heading or a section of a page, and not simply to add emphasis to text. For example, do not use a heading element to highlight the name of an account in the middle of a list of accounts.
Per the specifications:
The h1-h6 elements must not be used to markup subheadings, subtitles, alternative titles, and taglines unless intended to be the heading for a new section or subsection.
While this specification may seem straightforward, it can still be difficult to decide when a header should be used, as well as which one in particular. For the majority of instances, these decisions will be made for you and listed in the design for the widget you are working on. If they are not listed, we encourage you to work directly with the design team to help you decide which header flows would work best. When you need to make the decision on your own, ask the question, "If I were using a screen reader, would this heading make sense for me to navigate a page by?" Since headers are so crucial for (efficient) page navigation, the decision is really about how to optimize the screen reader experience.
Lately, we've begun to create a standard for where and when to use headers on our widgets. You can view examples using the following links:
Navigating the webpages
<nav> element is very similar to a
<header>, and represents a part of the document that links to other documents or to sections within the current page. Simply stated, the nav element is a section with navigation links.
<nav> element has an implicit ARIA role="navigation" attribute which is used to indicate to screen readers that there are more shortcuts available.
<nav aria-label="Site"> <!-- Screen readers read this as: "Site navigation" --> <ul> <!-- Unordered list with multiple links --> ... ... ... </ul> </nav>
Some forms of navigation include:
- Site navigation
- Section navigation
- Page navigation
- Utility navigation
- Footer navigation
<nav> element will usually wrap an unordered list, although it doesn't necessarily have to.
- Use the
<nav>element to indicate a section that links to other pages or sections.
- Always include the aria-label attribute, but do not use the word navigation.
Searching for something?
role="search" attribute defines an area where search functionality exists.
<div role="search" aria-label="Site"> ... ... ... </div>
Always include an
aria-label that describes the scope of your search, for example use "Site", "Transactions", "Accounts", "Payees", etc.
Complementary and not Contradictory
role="complementary" attribute is used to indicate an area that is complementary to the main content and still has meaning when separated from it. For example, a group of links that go to various areas on the site, like Help, Logout, or Contact Us, are complementary to the main content section, regardless of whether it is next to or independent from the main content.
<div role="complementary" aria-label="References"> ... </div>
Always add the
aria-label to express the scope of this complementary content. This makes it even easier for users to move directly to this region or browse a list of regions available on the page.
Sections and Articles
<section> element indicates a section in a document. Traditionally, a section will contain a heading. It should never be used solely as a styling wrapper as it has meaning to screen readers.
<section> <h2>Checking Account #234</h2> <header> <nav role="navigation" aria-label="Transactions"> ... ... ... </nav> </header> <article> <h3>Transaction #1</h3> ... ... ... </article> </section>
Footer and his cousin ContentInfo
role="contentinfo" attribute indicates an area that has information about the current document. This attribute often displays information like privacy statements and copyright information, and is usually attached to the footer.
The example in the screenshot below demonstrates the use of
role="contentifo" within the footer.
- Like with the
<header>element, you can use multiple
<footer>elements on any given page.
- Always include a relevant
- You can only use the
role="contentinfo"attribute once and it should either be on the page or in the body footer.
Native HTML5 elements
As you have seen from the sections above, many of the HTML5 elements have roles natively assigned to them. Let's take a look at a few more instances of these new elements to be aware of them and to be able to use them appropriately.
We've all used the more common input types that have been around for years, like text, radio, checkbox, and others. Now, HTML5 doubles the amount of available input types that we are able to use in our widgets. While most of these only offer a slightly improved performance on desktop browsers, mobile browsers get a great deal of benefit from these customized types.
Try to use a specific input type as often as possible to leverage the semantic creation of form fields and their internal logic.
When adding form fields, remember to:
- Always use a
<label>that is connected to the form
<input>field via the
- If there is any extra information to describe the input field, use the
aria-describedbyattribute to point to the id of the element containing the description
- Below is a good example of this, where a password input field has rules associated with it (8 characters long, upper and lowercase letters, and others).
<label for="phone_number">Phone Number:</label> <input type="tel" id="phone_number" /> <label for="password">Phone Number:</label> <input type="password" id="password" aria-describedby="password_rules" /> ... ... ... <div id="password_rules">Your password should be at least 8 characters long, contain uppercase and lowercase letters, and have a minimum of one special character.</div>
These are all of the new HTML5 input types (copied from Mozilla Developer Network (MDN) Web Docs):
color- HTML5 A control for specifying a color. A color picker's UI has no required features other than accepting simple colors as text.
search- A single-line text field for entering search strings; line-breaks are automatically removed from the input value.
tel- A control for entering a telephone number; line-breaks are automatically removed from the input value, but no other syntax is enforced. You can use attributes such aspattern and maxlength to restrict values entered in the control.
time- A control for entering a time value with no time zone.
url- A field for editing a URL. The input value is validated to contain either the empty string or a valid absolute URL before submitting. Line-breaks and leading or trailing whitespace are automatically removed from the input value. You can use attributes such as pattern andmaxlength to restrict values entered in the control.
week- A control for entering a date consisting of a week-year number and a week number with no time zone.
date- A control for entering a date (year, month, and day, with no time).
datetime- A control for entering a date and time (hour, minute, second, and fraction of a second) based on UTC time zone. This feature has been removed from WHATWG HTML.
datetime-local- A control for entering a date and time, with no time zone.
month- A control for entering a month and year, with no time zone.
number- A control for entering a floating point number.
password- A single-line text field whose value is obscured. Use the maxlength attribute to specify the maximum length of the value that can be entered.
range- A control for entering a number whose exact value is not important. This type control uses the following default values if the corresponding attributes are not specified:
Form Field Helper Text
Sometimes there will be helper text displayed below form fields. With screen readers parsing the DOM from top to bottom, we have to help make sure that the text gets announced beforehand.
<form> <label for="password_field">Password:</label> <input type="password" name="password" id="password_field" aria-describedby="password_field_instructions"> <span id="password_field_instructions">Your password must be six characters, contain at least one number, and at least one special character.</span> </form>
Buttons and Links
A good rule of thumb is: Buttons do something. Links go somewhere.
// Do this: <button>Fine... I'll do that thing for you</button> // Not this (the role here is redundant): <button role="button">Again... why do you keep clicking me?</button> // And definitely not this (just use a button): <a href="#" role="button" class="button">A link dressing up as a button</a>
Whenever you use a
<button> element, it's recommended that you also use a type. The existing types are:
- submit: This button will submit the form to the server. This is the default if nothing else is specified.
- reset: This will reset all of the controls to their initial values.
- button: A button has no default behavior. It is expected to have client-side scripts associated with its triggering.
For further information, see the MDN for articles on HTML buttons.
Tab order and Focus
The tab order is the order that a user moves in, from one control to another, when pressing the TAB key.
If you add
tabindex="0" to any element, that indicates to the screen reader that although this element is not in the usual list of elements to focus on, it does actually need to be read.
<span class="text-that-is-focusable" tabindex="0">I am now focusable!</span>
If managing focus programatically, adding
<div class="modal" tabindex="-1" aria-hidden="true"> ... ... ... </div>
// This makes sure that the browser gives proper focus and screen readers know this content is no longer hidden. $('.transaction-history-modal').focus().attr('aria-hidden', 'false'); // When the modal closes, we also need to remove focus and re-hide it from screen readers. $('.transaction-history-modal').attr('aria-hidden', 'true'); $('.previous-focused-element').focus();
Using Icon Fonts
When using icon fonts, remember to:
- Always provide off–screen text with an
aria-labelto describe what the icon indicates.
- Add an
role="img"attribute to allow the label text to be read by screen readers.
<div class="account-balance"> <span class="account-balance__icon font-icon-error" role="img" aria-label="Error syncing account balance"></span> <span class="account-balance__text">$4,827.92</span> </div>
Hiding content aurally
If you are thinking about hiding something from the screen reader. Please be aware that low vision users also exist. These users may be able to see both experiences. It is good practice to make both visual and aural experiences line up. If for some reason you are still needing to hide the UI from a screen reader, you can leverage the
This will ensure that the content is rendered and presented visually but is skipped over in the normal traversing of the DOM via a screen reader.
Screen reader only content
Sometimes, to make the best design experience, we will need to have content that the screen readers can use that does not need to be displayed on the screen. This could be instructions or links that help a screen reader user navigate the UI. There is no Aria control for this. You will need to use the CSS class
<a class="sr-only" href="#main">To Main Content</a> <span class="sr-only">Use the arrow keys to move the selection around.</span>