UltimateThemes.co.uk Accessibility Policy, Standards and Guidelines

Definition
Accessibility is identified as the service used to describe whether an item e.g. website, mobile phone application or television etc; can be used by people of all abilities and disabilities.

At Ultimate Themes, we aim to ensure that our website and supporting products are informative, entertaining and accessible for all users. This is known as usability.

On our website, accessibility is dependent on how a person’s disability affects the way they perceive information on a page and how they effectively navigate within and between pages.

Elements which can have an adverse affect on accessibility include:

  • For users who can’t see very well: The colours, the contrast between colours, the size of text and the choice of fonts have been selected for the purposes of a user.
  • For users who are listed as blind: How a website reader interprets the elements on a page for a friend or loved one e.g. alt tags for images, title tags for links and the inclusion of an audio narrative for video content.
  • For users who can’t hear very well: How any audio content is represented graphically e.g. signing on video content or subtitles for help with interpretation of content.
  • For users who find words/ wording difficult: The words and wording used; the complexity of the vocabulary; the choice of fonts selected and the size of text are selected for the purposes of the user.

At UltimateThemes.co.uk, we have taken all these factors into account and have produced an Accessibility policy, standards and guidelines to ensure we use best practice for our users.

When websites are correctly designed, developed and manipulated, all users can have equal access to the sites’ information and functionalities. Ultimatethemes.co.uk aims to make our website and supporting products accessible and usable for people of all abilities and disabilities, including older audiences, and those with impairments.

Many users employ assistive technologies to view websites in easier-to-read colours, with larger fonts or as spoken text, or to navigate around a site using the keyboard only.

As these assistive technologies become readily available to market, ultimatethemes.co.uk wants to ensure that our website and supporting products continue to work well with them to deliver a good experience for all users.

To help us to achieve these aims, UltimateThemes has produced and published its Policy, Standards and Guidelines. This document identifies a set of rules and regulations for anyone who is developing, designing or editing websites on behalf of UltimateThemes.co.uk.

The UltimateThemes policy comprises of two parts:

  • The accessibility standards specify the elements of a websites and supporting items that need to be looked at in more detail.
  • What UltimateThemes.co.uk consider and must consider when using design elements or features such as movement, Flash and multimedia, keyboard access, images and colour.
  • The accessibility guidelines provide recommendations and supporting information.

UltimateThemes.co.uk aims to ensure that its website and supporting tools are built in relation to the future development of operating systems, web browser and specialist assisting technologies, and the standards that allow all websites to be created to work best with these.

In instances where the specific accessibility requirements of a segment of users need assistance, UltimateThemes.co.uk will seek to accommodate those users by making new or re-purposed content where appropriate.

For more information, please contact support@ultimatethemes.co.uk

Accessibility Policy, Standards and Guidelines

The UltimateThemes.co.uk Online Accessibility Policy, Standards and Guidelines outline the requirements and recommendations necessary for ensuring all digital products are accessible to an array of audiences.

The standards and guidelines cover the technical aspects of accessibility and some user experience guidelines where these cross-over with technical implementation.

The UltimateThemes.co.uk Accessibility Standards and Guidelines will also cover techniques developed specifically for other digital platforms developed by the organisation.

Every web or mobile platform standard or guideline is listed with example code for implementing in HTML, Android, and iOS which is accompanied by the necessary recommended steps for testing.

The policy, standards and guidelines are developed specifically for the UK audiences in line with the technology used in the country. The standards and guidelines are to be used by employees of the UltimateThemes.co.uk web development team or any individual or organisation working on behalf of the organisation.

These standards have been derived and re-purposed from the BBC website through the  Open Government License for Public Sector Information website.

HTML Accessibility Standards v1.0

The Ultimate Themes HTML Accessibility Standards are a set of specific best practices for the websites content. Each standard is designed to be explicit and are listed with example code and steps for testing. These standards were developed specifically for UK audiences and for use with technology commonly available in the UK.

Core purpose

Before design and implementation of a document or feature, its core purpose must be defined.

Definitions: Core purpose is “the functionality to inform, educate, and entertain without which there would be no purpose for site or document.”

Rationale: While our aim is for all users to have access to all features of Ultimate Themes website and supporting digital products, we recognise that technology both restricts and extends what is possible.

Additionally, the UltimateThemes.co.uk is aimed providing the best experience to the broadest range of users, and while it should not discriminate against users with access needs, nor does it give special privilege.

The aim of this guideline is to provide the most accessible base line experience for the core purpose across the broadest range of technology.

See the following standards for examples of when a defined core purpose is applicable:

  • Progressive enhancement
  • Minimum text size

It is not a reason to ignore accessibility for non-core page elements.

Validation

All documents must have a W3C recommended Doctype and all Mark-up must validate against that Doctype.

Rationale: While assisting technologies such as screen readers generally do a good job of interpreting invalid HTML there will be less risk of problems arising if the document follows a recognised standard Doctype.

Techniques:

Pass:

<!DOCTYPE html>
<html lang=”en-GB”>

Fail:

<html lang=”en-GB”>

Tests

Procedure: Validate the page against the W3C Mark-up Validation Service
Expected Result: There must be no errors
Type Tool

Progressive enhancement

The core purpose of every document must not require JavaScript or CSS to function.

Rationale: We aim to provide a core experience to as broad an audience as possible, allowing users to choose the software and devices that work best for them in a broad range of circumstances.

Equally a robust site or application in the more traditional sense minimises its dependencies. The minimum dependency for a web site should be an internet connection and the ability to parse HTML.

CSS and JavaScript can, and should, be used to enhance the user experience beyond this basic level. For example, a ‘live’ page has a core purpose to provide the latest content about an event to the user. The core experience is the latest content at the time of the request. The experience enhanced with JavaScript automatically updates this content without the user having to take action.

Core experience: The experience that is provided to users without CSS or JavaScript.

Tests:

Procedure     Expected Result       Type
View the page with JavaScript and CSS disabled Verify that all core content is available and functional Manual

Indicating language

  • The main language of the page must be specified.
  • Changes to language within the page must be indicated.

Rationale: Assisting technologies such as screen readers have support for different languages, allowing for appropriate pronunciation.

Techniques

Pass:

<!DOCTYPE html>
<html lang=”en-GB”>
<head>
<title>Language techniques</title>
</head>
<body>
<h1>Techniques for language in HTML</h1>
<p><span lang=”es”>Cinco de Mayo</span> is Spanish for “fifth of May”</p>
</body>
</html>

Fail:

<!DOCTYPE html>
<html>
<head>
<title>Language techniques</title>
</head>
<body>
<h1>Techniques for language in HTML</h1>
<p>Cinco de Mayo is Spanish for “fifth of May”</p>
</body>
</html>

Tests

Procedure Search source for <html> element
Expected Result Element must have a lang attribute with a value equal to the language code for the main page content language
Type Manual
Procedure Validate the page against the W3C Internationalization Checker
Expected Result There must not be a ‘The html tag has no language attribute’ warning, and the Language HTML tag value should match the language code for the main page content language
Type Tool
Procedure Search source for each instance of a language change
Expected Result Each instance should have a containing element with a lang attribute with a value equal to the language code for the language
Type Manual

Page titles

Documents must have a page <title> that identifies its main content.

Rationale: Document titles help users orientate themselves within web sites and apps. The document <title> element content is often the first thing a speech output user will hear and acts as a confirmation of what page they have arrived at. Document titles commonly have the same content as the main <h1> element.

Techniques:

Pass:

<title>Ultimate Themes Policy, Standards and Guidelines</title>

Fail:

<title>Ultimate Themes</title>

Tests

Procedure Expected Result Type
Examine the title text of each document, either in a browser’s tab control or by viewing the document source and searching for the <title> element The document title should describe the primary content of the document Manual

Main landmark

A page must have exactly one element with role=”main”

Rationale: The WAI-ARIA main landmark role can be help keyboard users with assistive technologies such as screen readers (and in the future as native browser functionality) to skip directly to the main content of a page, bypassing navigation and other contents that might be before it.

Techniques:

Pass:

<div role=”main” id=”main-content”></div>

Fail:

<div id=”main-content”></div>

Tests

Procedure Search source for role=”main”
Expected Result There should be one instance of role=”main” as an attribute of an HTML element
Type Manual

Headings

  • A document must have exactly one <h1> element.
  • Heading levels after the document <h1> element must be sequential and must not skip heading levels.
  • Heading elements must be followed by content.

Rationale:

  • A logical heading structure is invaluable for users of screen readers and similar assisting technologies to help navigate content.
  • Users should be able to use the document’s <h1> identify its main content. Documents should have one main subject.
  • Heading levels should not be skipped as a predictable document outline is an important factor for understand-ability.
  • Headings should not be used for non-heading purposes, i.e. to identify blocks of content. A heading should always be followed either by non-heading content or by a heading of one level deeper.

Techniques:

Pass:

<div role=”main”>
<h1>Main page content</h1>
<p>Lorem ipsum…</p>
<h2>Secondary content</h2>
<h3>Tertiary content one</h3>
<ul>
<li>Lorem</li>
</ul>
<h3>Tertiary content two</h3>
<ul>
<li>Ipsum</li>
</ul>
</div>

Fail:

<div role=”main”>
<h3>Main content</h3>
<h2>Secondary content</h2>
<h2>Tertiary content</h2>
<p>Lorem ipsum…</p>
</div>

Tests

Procedure Use WAVE Toolbar or similar to generate a document outline
Expected Result There must be exactly one <h1>; No heading levels may be skipped after the <h1>;
Type Tool
Procedure Search document source for ‘</h1>’, ‘</h2>’, ‘</h3>’, ‘</h4>’, ‘</h5>’, ‘</h6>’
Expected Result There must be exactly one instance of ‘</h1>’ Each heading must be followed by content or another heading of one level deeper the <h1>;
Type Manual

Minimum text size

At default browser level all text must have a minimum calculated size of 11px and all core content must have a minimum calculated size of 13px.

Rationale: Having a minimum text size will reduce the number of users who need to make use of browser based text resize or page zoom. This is a particular issue with an ageing audience, many of whom will not consider themselves as having low vision and there will not have access to assisting technology or be familiar with browser tools to resize content.

Core content: The content that is required to fulfil the core purpose of the document or feature.

Techniques

Pass:

<style>

body {
font-size: 62.5%; /* Set default size of 1em to 10px */
}

news-article p {
font-size: 1.3em; /* Primary content size set to 13px */
}

.news-supplimentary-links {
font-size: 1.2em; /* Secondary content size set to 12px */
}

</style>

Fail:

<style>

body {
font-size: 62.5%; /* Set default size of 1em to 10px */
}

.news-article p {
font-size: 1.2em; /* Primary content size set to 12px */
}

.news-supplimentary-links {
font-size: 1em; /* Secondary content size set to 10px */
}

</style>

Test

Procedure For every piece of text of different sizes check the computed text size
Expected Result All content must have a minimum size of 11px
Type Manual, automatable
Procedure For every piece of core content text of different sizes check the computed text size
Expected Result All core content must have a minimum size of 13px
Type Manual

Resizable text

  • Text must be styled with units that are resizable in all browsers.
  • Content must be visible and usable with text resized to 200% of normal.
  • Content must be visible and usable with page zoomed to 200% of normal.
  • Where available on a platform zoom must be supported.

Rationale: Standard browser features for resizing text or page zoom can make content accessible to many low vision users without the need for additional assisting technologies such as screen magnifiers or screen readers.

Text resizing and page zoom cater to different needs, and therefore both should be supported.

Internet Explorer does not resize texts that have been styled in px units, therefore em, % or similar units should be used.

Browsers on iOS, Android, and other mobile platforms also support zoom with pinch-in and pinch-out gestures. In most cases it is just a matter of not disabling this, but there are some cases when it is appropriate to implement content specific interactions, such as with zoom-able maps, which should mimic the same pinch-in and pinch-out gestures.

Visible: Content is not clipped and does not overlap other content, and has sufficient spacing to make it readable.

Usable: Links, forms, and other controls are not overlapped with other elements making them un-clickable.

Techniques

Pass:

<style>

body {
font-size: 1.3em;
}

</style>

<meta name=”viewport” content=”user-scalable=YES”>
<meta name=”viewport” content=”width=device-width; initial-scale=1.0; maximum-scale=2.0; user-scalable=1;”>

Fail:

<style>

body {
font-size: 13px;
}

</style>

<style>

body {
overflow: hidden;
}

</style>

<meta name=”viewport” content=”user-scalable=no” />
<meta name=”viewport” content=”width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=1;”>

Test

Procedure In a browser that supports page zoom, increase the zoom level to 200
Expected Result All content must be visible and usable
Type Manual
Procedure In a browser that supports text resize, increase text resize to 200%
Expected Result All content must be visible and usable
Type Manual
Procedure In Internet Explorer, increase text resize
Expected Result All text content should increase in size
Type Manual
Procedure On platforms that support it, use pinch-in and pinch-out to zoom content
Expected Result All content should increase and decrease in size
Type Manual

Tabindex

  • Positive tabindex attribute values must not be used to create a logical tab order.
  • tabindex values of 0 must not be used on elements that are not focusable by default.

Rationale: Typical UltimateThemes.co.uk pages are made up of several shared components (navigation, page content, share tools, widgets, etc.) so no one piece of code has complete awareness of the content of the page or when the content updates. Positive tabindex values results in unpredictable tab order that do not occur if the natural order of content is relied upon.

Using tabindex=”0″ on an element adds it to the document tab order, however it does not change the element type to allow it to be discovered by navigating by link or form element, nor does it bind click and key press handlers to the element. There are no circumstances in which it is not better to use a natively focusable control such as a <a> or <button>.

Techniques

Pass:

<a href=”/news”>News</a>
<button type=”submit”>Search</button>
<div tabindex=”-1″></div>

Fail:

<a href=”/news” tabindex=”1″>
<button type=”submit” tabindex=”2″>Search</button>
<div tabindex=”3″></div>
<div tabindex=”0″></div>

Tests

Procedure Search source for tabindex
Expected Result There must be no instances of attributes with positive or 0 values
Type Manual

Title attributes

  • Title attributes must not be used for critical information and must not repeat content that is already visible and associated with the same control or content.

Rationale: Title attributes are inaccessible to keyboard users without additional assisting technology. They are dependent on user settings in Screen Readers and similar assisting technology.

Additionally they suffer from discover-ability problems: pointing device users are required to hover over page elements and pause before the title tool tip displays, usually with no indication that there is additional content to be displayed.

Repeating content in visible text and title attributes can lead to content clutter and repeated phrases.

Key recommendations are:

  • Do not use the title attribute unless on a form input as title text is not well supported on links on mobile
  • Do not use title attributes and explicit labels together on form fields

Techniques

Pass:

<label for=”name”>Name</label>
<input type=”text” id=”name” name=”name” />
<label for=”email”>Email</label>
<input type=”text” id=”email” name=”email” />
<button type=”button”><img src=”/path/to/image/close.png” alt=”Close” /></button>

Fail:

<input type=”text” name=”name” title=”Name” />
<input type=”text” name=”email” title=”Email” />
<label for=”name”>Name</label>
<input type=”text” id=”name” name=”name” title=”Name” />
<button type=”button” title=”Close”></button>
<a href=”/news” title=”News”>News</a>

Tests

Procedure Search source for all uses of the title attribute
Expected Result Ensure no instances contain content that would be required by all users or content that is repeated in associated content
Type Manual
Procedure Search source for all uses of the title attribute
Expected Result Ensure no instances contain content that is repeated within the element
Type Automated
Procedure Search source for all ‘’ elements and their associated form fields
Expected Result Ensure that the associated form field does not have a title attribute
Type Automated

Focus-able controls

  • Controls for JavaScript enhanced interactions must be <a>, <button>, or <input>[type=checkbox,color,date,datetime,datetimelocal,email,file,month,number,password,radio,range,search,tel,text,time,url,week] elements if that is the only mechanism for controlling them.
  • <a> elements used for controls must have an href attribute.
  • Controls that have no purpose without JavaScript must not be added to the page before the associated code is available capable of running.

Rationale: When creating controls for user interaction with JavaScript enhanced features, for example a carousel with previous and next controls, the controls must be implemented with elements that provide natively focusable elements with click, key down, and focus events so they are accessible to keyboard as well as pointing device users. If there is an alternative method of controlling the feature, for example a carousel that automatically displays new content when it receives content then controls that are only available to pointing device users can be used.

In general, use <a> elements when there is a URL associated with the interaction when JavaScript is not enabled, and <button> elements for interactions that don’t have an associated URL.

<a> elements without a href attribute are not keyboard accessible, and therefore must not be used for controls.

When there is no core (non-JavaScript) interaction then the control must not be added to the document before the associated JavaScript is capable of running as this would lead to controls that apparently do nothing, potentially causing confusion to users.

Techniques

Pass:

<button type=”button”>Open panel</button>

<ul>
<li><a href=”#newstab”>News</a></li>
<li><a href=”#sporttab”>Sport</a></li>
<li><a href=”#entertainmenttab”>Entertainment</a></li>
</ul>

Fail:

<a href=”#”>Open panel</a>

<ul>
<li><a>News</a></li>
<li><a>Sport</a></li>
<li><a>Entertainment</a></li>
</ul>

Tests

Procedure Identify each control on the page
Expected Result Navigate the page with a keyboard and ensure that each control is accessible
Type Manual

Visible on focus

Hidden elements in tab order must be made visible on focus.

Rationale: While it sometimes beneficial to provide content to screen reader users only, not all keyboard users also use a screen reader. Having hidden content in tab order, such as <a> or <button> elements, that remain hidden when focussed causes confusion for keyboard users that do not also use a screen reader.

It is recommended to use a clipping technique instead of negative positioning because of problems this can cause in iOS7 Safari, but either approach is accessible.

Techniques

Pass:

<style>

.hidden {
position: absolute; /* clip only relevant on absolutely positioned elements */
overflow: hidden;
height: 1px;
width: 1px;
clip: rect(1px 1px 1px 1px); /* For IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
}

.hidden:focus {
height: auto;
width: auto;
clip: auto;
}

</style>

<a href=”http://https://www.ultimatethemes.co.uk/” class=”hidden”>UltimateThemes</a>

Fail:

<style>

.hidden {
position: absolute;
top: -999em;
}

</style>

<div class=”hidden”>
<a href=”http://https://www.ultimatethemes.co.uk /”>UltimateThemes</a>
</div>

Tests

Procedure Tab through all elements in the document. Depending on browser / operating system you may need to activate tabbing through all controls (see Enabling keyboard navigation in Mac OS X Web browsers for OSX)
Expected Result All elements in tab order must be visible when they receive focus
Type Manual

Control styles

  • Links that are part of general editorial content must self evident, identifiable by their visual style, and distinguishable from the surrounding content.
  • Text links must have a mouse-over state change.

Rationale: To aid discover-ability all links must be made self-evident with their visual style.

Appropriate styles are:

  • underlined
  • a different colour, meeting contrast standards, to the surrounding text
  • When hovered over links should have a change in style as confirmation that they are links.

Appropriate styles are:

  • adding an underline to previously not underlined content
  • a change in colour, with a sufficiently different contrast to meet the contrast standard compared with the default state colour

Techniques

Pass:

<style>

body {
background: #fff;
color: #000;
}

a {

color: #005580;
text-decoration: none;
}

a:focus,
a:hover {
background: #fff;
text-decoration: underline;
}

</style>

<a href=”http://www.Ultimatethemes.co.uk/”>UltimateThemes</a>

Fail:

<style>

body {
background: #fff;
color: #000;
}

a {
color: #000;
text-decoration: none;
}

</style>

<a href=”http://www.bbc.co.uk/”>BBC</a>

Tests

Procedure For every <a> element check the visual style
Expected Result All <a> elements must be visually distinguishable from the surrounding content
Type Manual
Procedure For every <a> element check the visual style of the :hover state
Expected Result <a> elements must have a visually distinguishable style between :link and :hover states all
Type Manual

Focus styles

All focus-able elements must have a clearly identifiable visual style when they have focus

Rationale: Sighted keyboard users do not have the explicit association between pointer and content that pointing device users have, so it is important that they are aware at all times what element currently has focus and which element keyboard interactions will operate on.

The currently focused element should therefore have a visual style that makes it clearly distinguishable from the surrounding content.

Techniques

Pass:

<style>

a {
text-decoration: none;
}

a:focus {
text-decoration: underline;
}

</style>

Fail:

<style>

a {
outline: none;
}

</style>

Test

Procedure For every <a>, <button>, or other focusable element check the visual style of the :focus state
Expected Result All <a>, <button>, and other focusable elements must have a visually distinguishable style between their regular and :focus states
Type Manual

Colour contrast

All colour combinations must pass the WCAG 2.0 AA-compliant colour contrast check in accordance with the Snook colour contrast checker.

This is a ratio of 4.5:1 for text 18pt or less in size, and 3:1 for text larger than 18pt or text that is bold and larger than 14pt.

Where it cannot be adapted, stylised text used in per-existing broadcast logos and branding is exempt from this requirement.

Rationale: If there is sufficient contrast between foreground and background colours, particularly between text and its background but also applicable to the keys of graphs and similar, then users with moderately low vision or with colour deficiencies that affect contrast to a minor degree are more likely to be able to access Ultimate Themes content without requiring additional assisting technologies.

Techniques

n/a

Tests

Procedure Test every foreground and background colour combination against the Snook colour contrast checker
Expected Result Every combination must pass against the WCAG 2.0 AA standard
Type Manual Tool

Colour and meaning

Information conveyed with colour must also be identifiable from context or markup.

Rationale: Users who are blind, have low vision, or have colour blindness may not be able to differentiate content (lines on a chart) or states (selected tabs) if colour alone is used.

Alternatives must be provided for both sighted and non-sighted users, for example a table equivalent of a chart and lines differentiable with different styles (dashed, dotted, etc.).

Techniques

n/a

Tests

Procedure Locate every image or element that uses colour to convey meaning. Check visually and with a screen reader
Expected Result For each use of colour to convey meaning there must be alternative visual and non-visual means of accessing the same information
Type Manual Tool

Image alternatives

  • All images must have an alt attribute.
  • All editorial significant images must have a non-null alt attribute value, or a text alternative in the preceding or following content.

Rationale: Assisting technologies such as screen readers will provide a text alternative for images that do not have alt attributes based on the image file name. For images that do not have editorial significance or are described in the surrounding text content it is appropriate to use a null (alt=””) value for the image alt attribute to avoid this.

All editorially significantly images must have a text alternative either as the value of the alt attribute or in the immediately surrounding text content.

Techniques

Pass:

<img src=”UT-logo.png” alt=”UltimateThemes”>
<h1>Story headline</h1>
<img src=”story-image.png” alt=”Image”>

Fail:

<img src=”UT-logo.png”>
<h1>Story headline</h1>
<img src=”story-image.png” alt=”Story headline”>

Tests

Procedure Identify each image on the page
Expected Result Every image must have an alt attribute
Type Manual
Procedure Identify each editorially significant image on the page
 Expected Result Every editorially significant image must have a text alternative either as the value of the alt attribute or in the immediately surrounding text content.
Type Manual

Form labels

Form fields that allow input (select, and text area elements, and all input element types other than image, submit, reset, button, or hidden) must have an associated label, either in the form of a <label> element or, for simple forms when no visible label is required, a title attribute.

Rationale: Form labels are important for all users in order to understand what the form field is however they are essential for speech output users who cannot easily infer what the form element is by looking at the surrounding content.

While there are WAI-ARIA attributes that allow for labelling of forms it is not supported in all versions of assistive technologies that website users could reasonably expect to be able to use.

Techniques

Pass:

<label for=”search”>Search Ultimate Themes</label>
<input type=”text” id=”search” name=”q” />
<label for=”search”>
Search UltimateThemes.co.uk
<input type=”text” name=”q” />
</label>
<input type=”text” name=”q” title=”Search Ultimate Themes” />

Fail:

<input type=”text” name=”name” title=”Name” />
<input type=”text” name=”email” title=”Email” />
<input type=”text” name=”q” value=” Search Ultimate Themes” />
<input type=”text” name=”q” aria-label=” Search Ultimate Themes” />
<input type=”text” name=”q” placeholder=” Search Ultimate Themes” />

Tests

Procedure Use WAVE Toolbar (or similar) to identify accessibility errors
Expected Result There must be no ‘ERROR: Form label missing’ or ‘ARIA label or description’ messages
Type Tool
Procedure Check every select, and text area elements, and all input element types other than image, submit, reset, button, or hidden
Expected Result Every element must have either an associated <label> or a title attribute
Type Manual / Automated

Form interactions

All <form> elements that take user input (i.e. do not consist only of input [type=hidden] elements to store state) must have a submit button in the form of a <input>[type=submit, image] or <button>[type=submit] element.

Changes to the page must location must only take place on explicit user action i.e. when a submit button is activated. They must not take place when change (particularly for select elements), focus, or blur events are fired.

Rationale: All forms should have a submit button to provide a clear call to action. This is particularly important to users with cognitive disabilities, but is also beneficial to low vision users as an indication of the end of the form.

Techniques:

Pass:

<form action=”/search”>
<label for=”q”>Search term:</label>
<input type=”text” name=”q” id=”q”>
<input type=”submit” value=”Search”>
</form>

Fail:

<form action=”/search”>
<label for=”q”>Search term:</label>
<input type=”text” name=”q” id=”q”>
</form>

Tests

Procedure Expected Result Type
Identify every <form> or collection of form elements Each <form> or collection of form elements must have a submit button Manual
Test each <form> or collection of form elements Page location must not change on change, focus, or blur events Manual

Tables

Data tables must be marked up in a way that enables browsers and assisting technologies to identify them as such.

Rationale: Assisting technologies such as screen readers identify HTML tables as being either for data or for layout based on the mark-up used.

If a <table> is identified as a layout table then potentially useful structures may be ignored.

Algorithm: The following algorithm is used to determine if a <table> has been marked up in a way that allows browsers and assisting technologies to identify it as a data table:

  • Table inside editable area is data table always since the table structure is crucial for table editing
  • Table having ARIA table related role is data table (like ARIA grid or tree grid)
  • Table having ARIA landmark role is data table
  • Table having datatable=”0″ attribute is layout table
  • Table created by CSS display style is layout table

Table having summary attribute or legitimate data table structures is data table; these structures are:

<caption> element

<col> or <colgroup> elements

<tfoot> or <thead> elements

<th> elements

header, scrope or abbr attributes on table cell

abbr element as a single child element of table cell

Table having nested table is layout table

Table having only one row or column is layout table

Table having many columns (>= 5) is data table

Table having borders around cells is data table

Table having differently colored rows is data table

Table having many rows (>= 20) is data table

Wide table (more than 95% of the document width) is layout table

Table having small amount of cells (<= 10) is layout table

Table containing <embed>, <object>, <applet> of iframe elements (typical advertisements elements) is layout table

Otherwise it’s data table

Go through each check in turn, stopping when you reach a data table or layout table result.

Techniques

Pass:

<table>
<caption> Champions League Group C summary table</caption>
<thead>
<tr>
<th scope=”col”>Team</th>
<th scope=”col”>Score</th>
</tr>
</thead>

<tbody>
<tr>
<td>Malaga</td>
<td>12</td>
</tr>
<tr>
<td>AC Milan</td>
<td>8</td>
</tr>
<tr>
<td>Zenit Saint Petersburg</td>
<td>7</td>
</tr>
<tr>
<td>Anderlecht</td>
<td>5</td>
</tr>
</tbody>
</table>

Fail:

<table>
<tr>
<td>Team</td>
<td>Score</td>
</tr>
<tr>
<td>Malaga</td>
<td>12</td>
</tr>
<tr>
<td>AC Milan</td>
<td>8</td>
</tr>
<tr>
<td>Zenit Saint Petersburg</td>
<td>7</td>
</tr>
<tr>
<td>Anderlecht</td>
<td>5</td>
</tr>
</table>

Test

Procedure Expected Result Type
For each <table> element in the mark-up follow the defined algorithm All data tables must be identifiable as a data table Manual

Mobile Accessibility Standards and Guidelines v1.0

The UltimateThemes.co.uk Mobile Accessibility Standards and Guidelines are a set of technology agnostic best practices for the websites mobile content, hybrid and native applications.

Each standard and guideline is listed with example code for implementing in HTML, Android, and iOS and steps for testing.

The standards and guidelines are based on the requirements of ultimatethemes.co.uk content developed for UK audiences and for use with technology commonly available in the UK. They are intended as a standard for employees and suppliers to follow however they can also be referenced by anyone involved in mobile development.

The Standards and Guidelines are published in an HTML app with offline storage. This prototype app is designed to not only house the standards and guidelines but also act as a showcase for best practice.

Screen reader testing guidelines v1.0

This is the assisting testing (currently only screen readers) guide from the UX&D Accessibility team. This should inform your baseline testing. Your actual testing requirements should be based on usage statistics as with any other browser testing.

Overview

As with normal browser testing guidelines it is possible to provide general rules for which browsers to test with which screen readers. Because screen readers and other assisting technologies work in combination with browsers it is important to restrict the number of versions that are used during routine testing so that this does not take undue resources. Therefore for browsers and assisting technologies with good and practical upgrade paths the latest versions are sufficient testing. For browsers and assisting technologies with more problematic upgrade paths, for example due to ties to a particular operating system or expense, then a broader range must be considered, but should still be as few in number as possible.

For responsive sites, if differing screen sizes exposes different features you should test on sufficient variety of devices to expose all features.

JAWS: Test latest and latest -1 versions of JAWS with the latest version of Firefox, the latest version of Internet Explorer, Internet Explorer 8, and Internet Explorer 9.

Rationale: JAWS is expensive software and therefore has many users with older versions. Testing the latest and latest -1 versions provides reasonable coverage. It is also the most widely corporately supported screen reader which ensures it remains popular despite its price tag.

JAWS works best with Internet Explorer and Firefox so the majority of JAWS users will use one of these two browsers. If you have the capacity add the latest version of Google Chrome to the list for both versions of JAWS.

Windows XP, which continues to have a large market share despite Microsoft ending support for it, can only install up to Internet Explorer 8. Similarly, Windows Vista can only install up to Internet Explorer 9.

NVDA: Test latest version of NVDA with the latest version of Firefox, the latest version of Internet Explorer, Internet Explorer 8, and Internet Explorer 9.

Rationale: NVDA is free software, therefore it is reasonable to expect users to upgrade regularly. If you have spare capacity test with latest and latest -1 versions.

NVDA works best with Internet Explorer and Firefox so the majority of NVDA users will use one of these two browsers. If you have the capacity add the latest version of Google Chrome to the list. Windows XP, which continues to have a large market share despite Microsoft ending support for it, can only install up to Internet Explorer 8. Similarly, Windows Vista can only install up to Internet Explorer 9.

VoiceOver OSX: Test Voice Over on the latest version of OSX with Safari and Firefox and with latest and latest -1 version of Firefox.

Rationale: Voice Over is bundled with OSX and works best with Safari and Firefox so the majority of VoiceOver users will use one of these two browsers.

OSX 10.9 (Mavericks) is a free upgrade so it is reasonable to expect users to have an up to date version. If you have spare capacity test in OSX 10.8 (Mountain Lion).

If you don’t have a machine with the latest version of OSX installed then it is acceptable to test with the latest version available to you.

VoiceOver Ios: Test Voice Over on iPhone, iPad / iPad Mini, or iPod with the latest version of iOS / Safari. If differing screen sizes exposes different features you should test on sufficient variety of devices to expose all features.

Rationale: Voice Over is bundled with iOS and works best with Safari. iOS7 is a free upgrade available on iPhone 4 onwards, iPod Touch 5th generation, iPad 2 onwards, and iPad Mini 1st generation onwards so it is reasonable to expect users to have an up to date version. If you have spare capacity test on a device with iOS 6.

Talkback: Test TalkBack on Android phones and tablets with the latest versions of the OS and with the latest Chrome and Firefox browsers.

Rationale: TalkBack is bundled with Android since version 4. While browsing web content can freeze due to a lack of a keyboard on touch devices it is possible to install the Eyes-Free Keyboard to enable navigation within a web view.

Firefox on Android has as good TalkBack support as the default Chrome browser on Android 4+ and should be included where possible.

Any Questions?

Choose your currency:

Close
Converted prices are for reference only - all orders are charged in £ Pounds Sterling (£) GBP.
  • GBPPounds Sterling (£)