Accessibility Features

Accessibility overlaps with other best practices such as mobile web design, device independence, multi-modal interaction, usability, design for older users, and search engine optimisation. Accessible websites can have better search results, reduced maintenance costs, increased audience reach, and demonstrate corporate social responsibility.

W3C - Introduction to Web Accessibility

Accessibility by Design

We believe accessibility is important. An accessible website is about equality - making great, easy to use, understandable and accessible content for everyone. An accessible website improves the experience of all of your users, not just those who use assistive technology.

All of our sites and themes are designed and built to pass the Web Content Accessibility Guidelines (WCAG) 2.2 at the AA standard. W3C have published an "at a glance" overview of the guidelines at www.w3.org/WAI/standards-guidelines/wcag/glance

Some of our built in features are described below.

Focus

Whether navigating using the tab key or the mouse, all of our sites provide strong visual indicators for the position of the current focus.

Images

All of the background and decorative images in our themes have the appropriate attributes. See below for more information about the images you add to your own content.

Responsive

All of our themes are responsive. This not only makes them suitable to be viewed on any device, but also makes them easier to use at all levels of zoom.

Skip to Content

When navigating around a page using a keyboard the first element that the tab key will focus is a "Skip to main content" link. This link is invisible to sighted users until the tab key is pressed, but, as the first link in the body of the page, will immediately be available to screen reading software and keyboard users. Following the link skips past the page header and top level menus.

Text

Text size and contrast meet the requirements set out in the WCAG. We don't embed additional tools into our sites that switch to "high contrast" modes or enlarge text sizes. There are two main reasons for this.

Most importantly, users who need to enhance text beyond the recommendations will already have their own preferred way of doing so, using a favourite tool or browser extension. Providing a single high contrast mode may be perfect for one user, but awful for another.

Secondly, in-page text resizers can sometimes make content harder to read. By increasing the font size without scaling other page elements, layouts can break. For example, resizing text won't resize images. All browsers now have page resizing built-in which will do a better job than embedded tools.

Noscript Warnings

Some accessibility testing tools will alert you about the presence of <noscript> tags on your page. The presence of these tags is not an accessibility failure, rather, they are sometimes an indicator that a developer has tried to shoehorn in an accessibility fix, when what they should be doing is making the original script accessible.

There's a misconception that all JavaScript is bad for accessibility - it isn't. Bad JavaScript is bad for accessibility. This has led to a belief that users of assistive technologies will disable JavaScript, when a survey from WebAIM reported that over 98% of users had JavaScript enabled (https://webaim.org/projects/screenreadersurvey4/).

Testing tools highlight <noscript> tags as something to investigate further, ie is the original script accessible and why is an alternative being offered? The criteria for passing the warning is "Content and functionality provided by scripting is directly accessible to assistive technologies and the keyboard. <noscript> content does not constitute a suitable alternative to inaccessible scripting".

Our sites and themes will have a <noscript> tag as part of the Google Tag Manager implementation. This forms part of the embed code from Google which allows Tag Manager to function in the rare cases when JavaScript is disabled in someone's browser. As the Tag Manager script (or the noscript alternative) isn't providing functional content on the page, it is not an accessibility concern, as it's not something any user will actually interact with.

Creating Accessible Content

Accessibility relies on well written and structured content, and iCM has built in features that will help you create it. These tools are looked at in more detail in the documentation for your release of iCM. There's a summary of the latest features in the Creating Accessible Content article.

The main thing to say is don't turn these features off. iCM is completely customisable, but all of the accessibility tools, like checking headings are properly nested and that table properties are correct are turned on by default.

Remember that accessibility standards help identify websites that are definitely not accessible. However, meeting the standards doesn't automatically mean that your website is accessible - you need great content for that.

Images and Alt Text

When you create a media item in iCM you must enter a title and description. The description of the image is generally output as the image alt text.

However, just because you are required to enter a description doesn't immediately make it good alt text. WebAIM at the at the Centre for Persons with Disabilities at Utah State University have published this great guide to alt text: https://webaim.org/techniques/alttext (opens new window).

When adding images via inlines you have more control over the alt text and caption, see the Inlines - Standard Behaviour documentation.

Forms

The forms designer gives you the flexibility to build almost any type of form you can think of. That flexibility does mean you need to think about your form design and accessibility. Building Accessible Forms outlines best practice, and highlights some of the easily fixed mistakes we've seen.

Screen Readers

We don't encourage the use of embedded screen readers in our sites. There are several reasons for this.

As with text resizers and contrast modes, users who need assistive technology will, more than likely, already have their own preferred tool. No two screen readers are the same, and expecting a user to learn to use your chosen software just for your website is a big ask.

Some well known online screen readers have been criticised for poor use of JavaScript, relying on mouse clicks to use them, and have suffered from malware.

It's worth noting that the RNIB website does not include embedded text to speech tools.

Third Party Content

Pages on your site will inevitably include content embedded from other sources. This could include:

• Maps
• Videos
• Social media feeds
• Image galleries
• Surveys

These features are generally beyond our control when it comes to accessibility, however you can improve their accessibility by including an appropriate heading and describing the purpose of the content. You should also allow the embedded content to be opened in the source website (for example allowing an embedded Google Map to be opened in the Google Maps App or a new browser window).

Further Reading

https://webaim.org/articles/gonewild (opens new window) - A look at mistakes and misconceptions around accessibility

https://www.w3.org/TR/WCAG22/ (opens new window) - Web Content Accessibility Guidelines (WCAG) 2.2