Accessibility#
As of version 7.5, Arches can be configured to meet WCAG defined AA level accessibility requirements for all public-facing user interfaces. Please review the documentation on activating the Arches Accessibility Mode.
Please continue reading below to understand how to better meet accessibility requirements for your customization of Arches.
Contents#
Summary#
It is important that Arches is developed with inclusivity in mind by making it accessible to users with disabilities.
In a number of regions, organisations are required to ensure that any software they use, or provide as a service, is accessible for users with disabilities. To this end, any UI development within Arches must take measures to conform to the guidance set out in the WCAG 2.1 requirements. This will allow Arches to be more easily adopted by such organisations and provide benefits to a wider audience.
The following information details the minimum steps required to adhere to WCAG accessibility guidelines. Although the remit has been to adhere to AA standards, wherever possible AAA has been reached for issues such as color contrast.
Here’s a link to all the WCAG 2.1 requirements
You should ensure that you have developed and tested any code against these as a minimum when submitting code back to the project.
Tools Used#
Browsers - Chrome, Firefox and Safari (on iOS via Browserstack)
Browser extensions (all free, no sign-up required apart from Browserstack):
Browserstack - requires paid subscription
Key Points#
Although many files have been worked on for the many different requirements, there have been some frequently identified issues. Here are the commonly found problems:
Color Contrast#
Note
Tools used: Wave / Contrast checker
Using a combination of the Wave browser extension and the Contrast Checker website mentioned above, you can identify what elements on a page that need changing, for example, from the Arches v5 demo site, take the “Resource Type” button on the search page:
It has a background color #579DDB
and a foreground color #FFFFFF
- this fails the contrast test. You can use the contrast checker to test how things look when you lighten or darken either the background or foreground. In this instance, using the slider, let’s darken the background color to be #1E5A8F
instead, which passes WCAG AAA.
Form Fields#
Note
Tools used: Wave / Lighthouse / W3C HTML Validator / NVDA
Ensure form fields have correct labelling.
For example, instead of:
<h5>Field label text</h5> <input type="text">
use this code instead:
<label for="myField">Field label text</label> <input type="text" id="myField">
Sometimes it may suit design purposes not to have a label and make use of placeholder text. This is fine, but be mindful that users using screen readers will not get placeholder text read out to them. So we can make use of the aria-label
attribute:
<input type="text" id="myField" placeholder="Field label text" aria-label="Field label text">
…or using aria-labelledby
:
<span id="someText">Field label text</span> <input type="text" aria-labelledby="someText">
Also, you can use the aria-label
attribute on a container element to describe the content within:
<div class="container" aria-label="Search buttons to filter the search results"> <button id="filterBtn">Filters</button> <button id="typeBtn">Type</button> </div>
Headings#
Make sure that all headings are ordered and nested correctly. There should only be one <h1>
tag per page, and be sure to not skip any heading levels. The correct order should be something like this:
<h1>Main Heading</h1>
<h2>Navigation Menu</h2>
<h2>Sidebar</h2>
<h3>Profile</h3>
<h3>Settings</h3>
<h3>Help</h3>
...
Links#
Note
Tools used: Wave / W3C HTML Validator
If a link contains no text, then the function or purpose will not be understood by screen reader users.
For example:
<a href="">View more...</a>
or
<a>View more...</a>
…should be:
<a href="#" aria-label="View more search results">View more...</a>
…note the use of an aria-label
to provide a clearer description of what the link is for.
Keyboard#
Note
Tools used: none (manual checks required)
UI development must ensure the website/page is still navigable and actionable via the keyboard. There may be instances where click events are required on elements other than href
links, for example (using Knockout binding):
<div class="css-class" data-bind="click: function() {myFunc();}">
Some content
</div>
This will listen for a mouse click on the div
element, but this won’t work if a user is using their keyboard to navigate and operate the website. A keyboard user will not be able to tab
to this element or be able to action it by pressing their space bar or enter key. To facilitate this, we need to make it tabbable
and actionable via a keypress
as follows:
<div class="css-class"
tabindex="0"
data-bind="click: function() {myFunc();}"
onkeypress="$(this).trigger('click');">
Some content
</div>
Note the use of tabindex="0"
which includes the element within the natural DOM tab order and the onkeypress
which in this example uses jQuery to force a click
. There may be several ways to achieve this but always ensure any clickable element can also be actioned using a keyboard, usually the enter key once tabbed to.
Responsive Design#
Note
Tools used: Lighthouse / Browserstack / Browsers (Chrome, Firefox and Safari)
When designing websites, we must think about all users and not for example, only desktop or laptop users with large screens. Users with visual impairment may increase the font size or spacing, or possibly the screen resolution may be lower.
By developing a responsive application, users making these adjustments will benefit from the application adjusting correctly to it. The application will also benefit from this by being available on tablets and mobile devices and in some regions, mobile phones are peoples’ only computing device.
The website should offer the same functionality whether viewing on a large monitor or mobile screen and anything in between so that we can be as inclusive as possible. If certain information cannot be viewed on a smaller screens, then a suitable alternative should be presented to the user.
Arches uses the javascript library called Bootstrap which enables the content to be rendered in a grid system that can be adapted to suit varying screen sizes and types, including mobiles and tablets. No content should appear ‘cut-off’ when reducing the screen width; it should either stack, wrap or be presented differently.
This can easily be tested in a browser such as Chrome or Firefox which have built in developer tools for viewing at different devices or screen widths. Of course the ultimate test would be to use an actual device to see what happens in the real world. For this level of testing I would recommend Browserstack which has access to many different physical devices and browsers.
It’s also good practice to ensure that web pages operate the same using different web browsers. For example, some things may not work correctly in Safari or Chrome, but everything seems fine in Firefox.
HTML Validation#
Note
Tools used: W3C HTML Validator
Any rendered html
needs to pass W3C HTML Validator tests. With any dynamically produced web page, it’s easy to load the page in a browser and view the source, copy and paste into the ‘Validate by direct input’ form field, run the test and work on any errors as necessary.
Here are some common issues found:
Empty id and class attributes, like
id=""
andclass=""
- if they’re empty remove themIncorrect html markup, like having a div tag inside a span tag
Incorrect html5 semantic markup - for example no landmarks, no header, no main, no footer etc
On some pages, the first code on a page contains the open source copyright comment, which is acceptable and required by the GNU Affero General Public License, but sometimes the comment is duplicated causing a validation error
Screen Reader#
Always be mindful of users that require to use screen readers and check how sections of the page are read out and in what order.
For desktop checks, use the NVDA application to identify possible changes or where to include some aria-label
descriptive text to assist with the content visualisation.
Mobile devices have some built in screen reader technology. For iOS it’s called Voice Over and can be accessed under Settings>Accessibility
. For Android devices it’s called Screen Reader and can be accessed via Settings>Accessibility>Screen reader
.
For example, when viewing a web page, one of the first things read out may be the menu. If the menu has many items, this could become a tedious activity, so it’s good practice to include a “Skip to main content” link that appears when a user first presses the tab button. Pressing enter should change focus to the start of the main content, bypassing the menu items.
Alternative solutions where components cannot be made accessible#
In the event that a specific component cannot be made fully accessible, an alternative method of achieving the same outcome should be provided.
For example, if using an SVG canvas type library to display information or provide a search function, a tabular alternative could also be created that provides the same function.
Ideally, the accessible solution would be the primary solution.
Additional Points#
There are many more WCAG guidelines that need to be adhered to but these mentioned here are among the most common. It’s always good practice to have these points in mind whenever creating web pages/content. Always keep in mind how a keyboard-only user would be able to interact with pages and how they would still work on smaller devices such as tablets or mobiles.
Even though your targeted users may not be using mobile devices, you have to cater for every need. In this day and age, the “Mobile first” principle should be used and play a significant role in any product design/development work.