bbc-a11y 0.0.2

data/features/09_tabindex.feature

@@ -0,0 +1,38 @@
+Feature: Correctly use `tabindex` attributes
+
+  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 BBC pages are made up of several shared components (Global navigation, page content, share tools, location service 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>
+
+
+  Scenario: Check all tabindex values
+    When I visit the page
+    Then there should be no elements with a tabindex attribte of 0 or greater

data/features/10_form-labels.md

@@ -0,0 +1,47 @@
+# Correctly use form labels
+
+Form fields that allow input (`select`, and `textarea` 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 BBC users could reasonably expect to be able to use.
+
+## Techniques
+
+Pass:
+
+	<label for="search">Search the BBC</label>
+	<input type="text" id="search" name="q" />
+
+	<label for="search">
+		Search the BBC
+		<input type="text" name="q" />
+	</label>
+
+	<input type="text" name="q" title="Search the BBC" />
+
+Fail:
+
+	<input type="text" name="name" title="Name" />
+	<input type="text" name="email" title="Email" />
+
+	<input type="text" name="q" value="Search the BBC" />
+
+	<input type="text" name="q" aria-label="Search the BBC" />
+
+	<input type="text" name="q" placeholder="Search the BBC" />
+
+## Tests
+
+| Procedure | Expected Result | Type | 
+| --------- | --------------- | ---- |
+| Use WAVE Toolbar (or similar) to identify accessibility errors errors | There must be no 'ERROR: Form label missing' or 'ARIA label or description' messages | Tool |
+| Check every `select`, and `textarea` elements, and all `input` element types other than image, submit, reset, button, or hidden | Every element must have either an associated `<label>` or a title attribute | Manual / Automated |
+
+--
+
+## Notes
+
+Hopefully the second test can be automated. Associated labels are those that wrap the element (`<label>Foo <input type="text" /></label>`) and those that have a `for` attribute value that matches the `id` attribute of a field element (`<label for="foo">Bar</label><input type="text" id="foo" />`). In the second case the `<label>` can wrap the form element, but does not have to.

data/features/11_visible-on-focus.md

@@ -0,0 +1,58 @@
+# Visually hidden elements must be made 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 recommened 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://www.bbc.co.uk/" class="hidden">BBC</a>
+
+Fail:
+
+	<style>
+	.hidden {
+		position: absolute;
+		top: -999em;
+	}
+	</style>
+
+	<div class="hidden">
+		<a href="http://www.bbc.co.uk/">BBC</a>
+	</div>
+
+## Tests
+
+| Procedure | Expected Result | Type | 
+| --------- | --------------- | ---- |
+| 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](http://www.456bereastreet.com/archive/200906/enabling_keyboard_navigation_in_mac_os_x_web_browsers/) for OSX) | All elements in tab order must be visible when they receive focus | Manual |
+
+--
+
+## Notes
+
+Matt: I don't see how this can be automated, but it would be great if I was wrong.

data/features/13_colour-contrast.md

@@ -0,0 +1,27 @@
+# All content must meet minimum contrast standard
+
+All colour combinations **must** pass the WCAG 2.0 AA-compliant colour contrast check in accordance with the [Snook colour contrast checker](http://snook.ca/technical/colour_contrast/colour.html).
+
+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 pre-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 BBC content without requiring additional assistive technologies.
+
+## Techniques
+
+n/a
+
+## Tests
+
+| Procedure | Expected Result | Type | 
+| --------- | --------------- | ---- |
+| Test every foreground and background colour combination against the [Snook colour contrast checker](http://snook.ca/technical/colour_contrast/colour.html) | Every combination must pass against the WCAG 2.0 AA standard | Manual / Tool |
+
+--
+
+## Notes
+
+This (and every other test that requires checking a large number of elements and their properties) would be best run as part of the 'full' test set, and have a 'quick' test set for any standards that are quick to test.

data/features/14_colour-meaning.md

@@ -0,0 +1,19 @@
+# Information must not be conveyed by colour alone
+
+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 | Expected Result | Type | 
+| --------- | --------------- | ---- |
+| Locate every image or element that uses colour to convey meaning. Check visually and with a screen reader | For each use of colour to convey meaning there must be alternative visual and non-visual means of accessinging the same information | Manual / Tool |

data/features/15_focusable-controls.md

@@ -0,0 +1,45 @@
+# Correctly use links and buttons
+
+Controls for JavaScript enhanced interactions **must** be `<a>`, `<button>`, or `<input>[type=checkbox,color,date,datetime,datetime-local,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, keydown, 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 | Expected Result | Type | 
+| --------- | --------------- | ---- |
+| Identify each control on the page | Navigate the page with a keyboard and ensure that each control is accessible | Manual |

data/features/16_table.md

@@ -0,0 +1,109 @@
+# Correctly markup data tables
+
+Data tables **must** be marked up in a way that enable browsers and assistive technologies to identify them as such.
+
+## Rationale
+
+Assistive technologies such as screen readers identify HTML tables as being either for data or for layout based on the markup used.
+
+If a `<table>` is identified as a layout table then potentially useful structures may be ignored.
+
+## Definitions
+
+### Algorithm
+
+The following algorithm is used to determine if a `<table>` has been  marked up in a way that allows browsers and assistive technologies to identify it as a data table:
+
+1. Table inside editable area is data table always since the table structure is crucial for table editing
+2. Table having ARIA table related `role` is data table (like ARIA `grid` or `treegrid`)
+3. Table having ARIA landmark `role` is data table
+4. Table having `datatable="0"` attribute is layout table
+5. Table created by CSS `display` style is layout table
+6. 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
+7. Table having nested table is layout table
+8. Table having only one row or column is layout table
+9. Table having many columns (>= 5) is data table
+10. Table having borders around cells is data table
+11. Table having differently colored rows is data table
+12. Table having many rows (>= 20) is data table
+13. Wide table (more than 95% of the document width) is layout table
+14. Table having small amount of cells (<= 10) is layout table
+15. Table containing `<embed>`, `<object>`, `<applet>` of iframe elements (typical advertisements elements) is layout table
+16. 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 markup follow the defined algorithm | All data tables must be identifiable as a data table | Manual |
+
+--
+
+## Notes
+
+Hopefully this is clear enough.

data/features/17_control-styles.md

@@ -0,0 +1,78 @@
+# Links must be self-evident
+
+Links that are part of general editorial content **must** be identifiable by there visual style and be distinguishable from the surrounding content.
+
+Text links **must** have a mouse-over state change.
+
+## Rationale
+
+To aid discoverability 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: 
+			text-decoration: underline;
+		}
+	</style>
+	
+	<a href="http://www.bbc.co.uk/">BBC</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 | Expected Result | Type | 
+| --------- | --------------- | ---- |
+| For every `<a>` element check the visual style | All `<a>` elements must be visually distinguishable from the surrounding content | Manual |
+| For every `<a>` element check the visual style of the `:hover` state | All `<a>` elements must have a visually distinguishable style between `:link` and `:hover` states | Manual |
+
+--
+
+## Notes
+
+Might be difficult to automate the first test. It might be possible (but expensive) to check every link on a page against the style of its parent element, comparing colour, underlines, weight, and other styles but at best I feel this could only be an error if there are no style changes.
+
+The second test is testing two states of the same element so might not be quite as difficult (providing you have access to the :hover styles) but it's still hard to have a high degree of confidence in the outcome.
+
+Perhaps we need to have a warning rather than an error for these tests.

data/features/18_focus-styles.md

@@ -0,0 +1,36 @@
+# Focusable elements must have a clear visual indication when they receive focus
+
+All focusable 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 focussed 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 | Expected Result | Type | 
+| --------- | --------------- | ---- |
+| For every `<a>`, `<button>`, or other focusable element check the visual style of the `:focus` state | All `<a>`, `<button>`, and other focusable elements must have a visually distinguishable style between their regular and `:focus` states | Manual |

data/features/19_form-interactions.md

@@ -0,0 +1,33 @@
+# Forms must have a submit button and forms must not update the location of the page on change, focus, or blur events
+
+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 |

data/features/20_image-alt.md

@@ -0,0 +1,34 @@
+# Image alternative content
+
+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
+
+Assistive 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="bbc-logo.png" alt="BBC">
+
+    <h1>Story headline</h1>
+    <img src="story-image.png" alt="">
+
+Fail:
+
+    <img src="bbc-logo.png">
+
+    <h1>Story headline</h1>
+    <img src="story-image.png" alt="Story headline">
+
+## Tests
+
+| Procedure | Expected Result | Type | 
+| --------- | --------------- | ---- |
+| Identify each image on the page | Every image must have an alt attribute | Manual |
+| Identify each editorially significant image on the page | Every editorially significant image must have a text alternative either as the value of the alt attribute or in the immediately surrounding text content. | Manual |

data/features/21_min-font-sizes.md

@@ -0,0 +1,64 @@
+# 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 assistive technology or be familiar with browser tools to resize content.
+
+## Definitions
+
+### 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 | Expected Result | Type | 
+| --------- | --------------- | ---- |
+| For every piece of text of different sizes check the computed text size | All content must have a minimum size of 11px | Manual, automatable |
+| For every piece of core content text of different sizes check the computed text size | All core content must have a minimum size of 13px | Manual |
+
+--
+
+## Notes
+
+The core content problem again so we can only realistically automate testing against the 11px minimum.
+
+It could be an expensive operation to get the computed style for every text node in a document, and it is tests like this that made me think about having grades of tests based on how quickly they are likely to run. You don't need to run this test every time a CSS change is made, but it is worth running before committing.
+
+It is likely that entire parts of the page will be considered 'core', for example everything in the page `<main>` element, so would it be possible to write this in such a way as to make it easy for individualy products to add their custom rules to test for the 13px minimum within certain elements?

data/features/22_resize-zoom.md

@@ -0,0 +1,80 @@
+# Content must be resizable to 200
+
+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 suported.
+
+## Rationale
+
+Standard browser features for resizing text or page zoom can make content accessible to many low vision users without the need for additional assistive 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 text 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 zoomable maps, which should mimic the same pinch-in and pinch-out gestures.
+
+## Definitions
+
+### 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 | Expected Result | Type | 
+| --------- | --------------- | ---- |
+| In a browser that supports page zoom, increase the zoom level to 200% | All content must be visible and usable | Manual |
+| In a browser that supports text resize, increase text resize to 200% | All content must be visible and usable | Manual |
+| In Internet Explorer, increase text resize | All text content should increase in size | Manual |
+| On platforms that support it, use pinch-in and pinch-out to zoom content | All content should increase and descrease in size | Manual |
+
+--
+	
+## Notes
+
+The first two tests will have to be manual I think, but is it possible to make automate the 'px' test?