July 2020

August 2020

September 2020

October 2020

November 2020

December 2020

January 2021

February 2021

March 2021

April 2021

May 2021

June 2021

July 2021

August 2021

September 2021

October 2021

November 2021

December 2021

January 2022

February 2022

March 2022

April 2022

May 2022

June 2022

July 2022

August 2022

September 2022

October 2022

November 2022

December 2022

January 2023

Joseph Rowntree Housing Trust

Screen reader users will see links on a page listed without context, 
so you should ensure the same link text is not used to point to different web
addresses.

For example:

```html
<p>
    Learn the latest about our products: 
    <a href="/products/news">News</a>
</p>

<p>
    Learn the latest about our services: 
    <a href="/company/news">News</a>
</p>
``` 

To a screen reader who is listing links, they will only hear:

* News
* News

These links appear to be the same, but they both behave differently. 
One solution, which doesn't require the page design to change, is to add an 
`aria-label` for each link:

```html
<p>
    Learn the latest about our products: 
    <a href="/products/news" aria-label="Product news">News</a>
</p>

<p>
    Learn the latest about our services: 
    <a href="/company/news" aria-label="Company news">News</a>
</p>
``` 

Which will be heard as:

* Product news
* Company news

To pass this checkpoint, make sure that links which point to different pages 
have distinct text inside them, or that they specify ARIA labels (`aria-labelledby` or
`aria-label`), or they use hidden text only visible to screen readers
(e.g. `<span class="sr-only">...</span>`) to distinguish them from each 
other.

If links point to the same page (e.g., they redirect or use tracking
parameters, but are functionally equivalent to the user) you can ignore
this issue.

a-duplicate-link-text-for-different-destinations

To comply with the strictest accessibility standard (WCAG AAA), the colour of text must 
strongly contrast with its background color, so that people with significant visual impairments 
can read it.

The [contrast ratio](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#contrast-ratiodef)
must be at least 7:1 for body text, and 4.5:1 for large text.

A far less demanding version of this check (1.4.3) exists for WCAG AA. All websites should aim to 
meet the easier AA standard at a minimum. The AAA standard is desirable but far more challenging,
and may not be practical for your website.

aaa-text-contrast

Tables which contain information should have clear headers defined.  

In this example, the top row of the table is a header:

| Surname        | City          |
| -------------- | ------------- |
| Washington     | London        |
| Phoenix        | Arizona       |
| Austin         | Travis        |

Notice how without the header here, it would be almost impossible to understand 
what the individual values mean ("Washington" could be a city or a surname). 

It is not enough to just make the headers look differently, as accessible technologies will not 
recognize this (for example, a screen reader cannot 'see' different colors or fonts). 
Table headings must be defined using the `<th>` tag. 

This example shows how a table should use a `<th>` to mark cells as headings. Note the 
use of the `col` attribute, to specify these headings are for the _column_:

```html
<table>
  <tr>
    <th scope="col">First name</th>
    <th scope="col">City</th>
  </tr>
  <tr>
    <td>Washington</td>
    <td>London</td>
  </tr>
  <tr>
    <td>Phoenix</td>
    <td>Arizona</td>
  </tr>
  <tr>
    <td>Austin</td>
    <td>Travis</td>
  </tr>
</table>
```

Tables which are used purely for layout do not need to do this. However, 
[the use of tables for layout is strongly discouraged](https://www.lifewire.com/dont-use-tables-for-layout-3468941).
This check will ignore tables that it believes are purposely used for layout.

Learn more about [accessible table design (W3C)](https://www.w3.org/WAI/tutorials/tables/one-header/).

add-header-to-tables

Links must be defined in a specific way to be accessed by screen readers, which are used by 
blind and the partially-sighted.

To work with accessibility technologies, links must contain both machine-readable text, and 
a `href` attribute. If a link is not actually
pointing to a page or part of a page, it should be replaced with another semantic element, such
as a `button`, or the `<a>` tag should have a role of `button`. 

For example:

```html
<a href="/about">About us</a>
```

If the link contains _nothing but an image_, that image should specify alternative text, e.g.

```html
<a href="/apple">
    <img src="apple.png" alt="Apple">
</a>
```

Before HTML5, an anchor was often used to create a target to link to, e.g.

```html
<a name="example"></a>
```

This is not supported in HTML5, and the use of anchors for targets is discouraged. Use an `id`
attribute on a non-anchor tag instead, e.g.

```html
<div id="example"> ... </div>
```

Empty links (e.g. `<a></a>`) are often incorrectly used for buttons or controls in a
JavaScript application. In these cases, you should usually define the link as having a more appropriate
role, e.g. as a button. To do this, use the `role` attribute (e.g `<a role="button">`), or replace 
the `<a>` tag with a more appropriate tag, such as `<button>`.

For more details, see [Technique H91](https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H91)
and learn about [ARIA roles](https://www.sitepoint.com/how-to-use-aria-effectively-with-html5/).

bad-anchor

Heading elements (`<h1>`, `<h2>`, ...) must contain some machine-readable
text content. 

Heading should never be empty, or just contain whitespace:

```html
<h1>   </h1>
```

Headings which contain images or other media must specify alternative text:

```html
<h1>
    <img src="heading.png" alt="Press releases"> 
</h1>
```

See [Technique H42](https://www.w3.org/TR/WCAG20-TECHS/H42) for more details.

empty-heading-content

All controls on the page - including links, buttons, and fields - should clearly 
indicate when they have been selected by the keyboard.

This is a stricter version of [WCAG 2.4.7](https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html),
which requires that the focus indicator is visible, but doesn't specify how clearly
it should be visible.

You can confirm this yourself by loading a webpage and using the Tab key to navigate 
through it. Anything you can select should clearly alter its appearance when selected. 
For example, a text field might change color, or have a distinctive border applied. 

## The requirements

The [official requirements](https://w3c.github.io/wcag/understanding/focus-appearance.html) are 
complicated. A simplified version is:

* Surround the control with a solid outline
* The outline must have at least 3:1 contrast with its background
* The outline must have at least 3:1 contrast with its surroundings, or be at least 2px thick

The actual requirements allow for more variation, but generally require that you 
calculate the perimeter and/or area of the focus area, which can be very difficult.

## How to fix

Links and form controls should use a focus selector which contrasts with their
unfocused state, as well as any surroundings of the focus state. 

In practice, the easiest way to accomplish this is to use a two-color focus, like so:

```css
/* ensure high-contrast mode still has an indicator */
outline: 2px transparent solid;

/* Apply a thick yellow box-shadow with 
   a thin dark blue indicator in the middle */
box-shadow: 0 0 0 2px #F9F9D1, 0 0 0 4px #396196, 0 0 4px 8px #F9F9D1;
``` 

From [Technique C40](https://www.w3.org/WAI/WCAG22/Techniques/css/C40).

Using two contrasting colors guarantees that the focus state will be visible, 
regardless of the background or surrounding colors.

## Troubleshooting

### Elements appear to change in the browser

Focus states should be defined in CSS alone, and not require JavaScript to work. 

Try disabling JavaScript on the page, and see if focus is still visible. If it not, 
then the focus state won't work with assistive technologies that don't have a physical
keyboard, e.g. mobile phones.

Some more unusual means of implementing a focus state cannot be detected or measured
automatically. These include:

* Focus implemented via pseudo-elements - such as `::after` or `::before`. 
* Focus using `:focus-within` (JavaScript current provides no way to access these).
* Focus cascaded to child elements, e.g. a `<span>` inside an `<a>` tag. We detect
  some of these cases, but there are variations that we cannot detect.

Currently, there is no practical way to assess these focus states automatically.

### Elements over images not analyzed

Silktide cannot assess the contrast of elements that are over images. This is because
the contrast of an element is calculated by comparing the color of the element with the
color of the background. 

If the element is over an image, the background color is the
color of the image, which varies from pixel-to-pixel, and may vary further as the page
is resized, due to responsive design.

### Unexpected elements are focusable

You may be surprised to see tags like `<div>` or `<span>` being shown as focusable.
If an element has a `tabindex` of 0 or higher, it becomes focusable. Any HTML tag can be made 
focusable in this way, this is so that custom controls (e.g. your own drop-down menus, or 
sliders) can support keyboard navigation. [Learn more about tabindex on MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex).

## Further reading

This is part of the draft WCAG 2.2 specification and is subject to change.

* [WCAG 2.4.11](https://w3c.github.io/wcag/understanding/focus-appearance.html)

ensure-focus-appearance

When selecting a user interface component with the keyboard, the focus indicator must 
not be partly obscured by anything in front of it. This is the stricter version of this check for 
Level AAA.

## Why this matters

When using a keyboard, it is important that the user can see where they are on the page.
If the focus indicator is obscured, the user may not know where they are, and may not
be able to interact with the page.

## Examples

Most common examples include:

* Banners at the top or bottom of the page, such as cookie banners
* Fixed navigation bars
* Fixed footers
* Popup modals, such as cookie consent modals

## How to fix

With elements that cover part of the screen, such as cookie banners, ensure
that the user can scroll to see any content behind the banner, without having to close
the banner.

With popup modals, it should usually be impossible to focus anything behind the modal.
Most common modal frameworks will automatically trap focus within the modal, so that
this is impossible. Example: [Bootstrap Modal](https://getbootstrap.com/docs/5.2/components/modal/#live-demo).

## Further reading

This is part of the draft WCAG 2.2 specification and is subject to change.

* [WCAG 2.4.13](https://w3c.github.io/wcag/understanding/focus-not-obscured-enhanced.html)

ensure-focus-is-not-obscured-enhanced

When selecting a user interface component with the keyboard, the focus indicator must 
not be completely obscured by anything in front of it.

## Why this matters

When using a keyboard, it is important that the user can see where they are on the page.
If the focus indicator is obscured, the user may not know where they are, and may not
be able to interact with the page.

## Examples

Most common examples include:

* Banners at the top or bottom of the page, such as cookie banners
* Fixed navigation bars
* Fixed footers
* Popup modals, such as cookie consent modals

## How to fix

With elements that cover part of the screen, such as cookie banners, ensure
that the user can scroll to see any content behind the banner, without having to close
the banner.

With popup modals, it should usually be impossible to focus anything behind the modal.
Most common modal frameworks will automatically trap focus within the modal, so that
this is impossible. Example: [Bootstrap Modal](https://getbootstrap.com/docs/5.2/components/modal/#live-demo).

## Further reading

This is part of the draft WCAG 2.2 specification and is subject to change.

* [WCAG 2.4.12](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured.html)

ensure-focus-is-not-obscured-minimum

Most content should be written so people with a lower secondary level of education can understand it.
Where this is not possible, supplemental content or an alternative version should be provided.

This check highlights pages with a reading age of 16 years or higher. Only pages with at least 100 words
of content (excluding navigation, footers, etc) are considered.  

For more information, see [WCAG SC 3.1.5](https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-supplements.html).

ensure-reading-ability-is-not-advanced

All interactive components on a page, such as buttons or fields, should ideally be large enough 
to be easily used by people with motor impairments. 

This ensures people with motor impairments can easily click or tap on the element.

The recommended size is 44 x 44 CSS pixels, with some exceptions:

* **Equivalent available** - the functionality provided by
  the control is available elsewhere, and large enough, on the same page.
* **Inline text** - the control appears inside a sentence or block of text. 
* **User Agent control** - the size of the target is determined by the user agent 
  and is not modified by the author. Generally this is not the case for web content.
* **Essential** - the size of the target is essential to the information being conveyed,
  e.g. a tutorial demonstrating what a small button looks like. This exception is rare.

## Applying this check

Nearly all websites will fail this check by default. The minimum size requirement
is larger than most links and controls on most websites.

This is the much stricter version of the WCAG 2.2 AA check for target size. Most websites
should focus on the AA check before considering this AAA check:

* [Target Size (Minimum)](https://w3c.github.io/wcag/understanding/target-size-minimum.html)

## Methodology

This check is run on both the mobile and desktop versions of every page. Results
for each may differ.

1. All interactive elements are identified, including buttons, links, and form controls. 
2. If an element is proceeded or followed directly by a non-empty text node, the control
   is ignored.
3. If an element is not normally visible, it is ignored. This includes elements which 
   are positioned offscreen or cropped (e.g. for 'screen-reader only' text).
4. If an element is a link, and another visible link on the page points to the same URL, with 
   that other link meeting the size requirements, the element is ignored.
5. Otherwise, the element must have a minimum size of 44 x 44 CSS pixels.

## Troubleshooting

Silktide only records the first 100 instances of a failure on a page. Because failures
of this check are common, it is possible that your page has more than 100 failures, but
only the first 100 will be shown.

## Further reading

* [Target Size (Enhanced)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced)

ensure-reasonable-target-size

To comply with WCAG 2.1, fields must identify what their purpose is _programmatically_. If done correctly,
this allows browsers to help users fill in forms with known information, such as their name and email address.

This is accomplished via the `autocomplete` attribute, which should be set to a 
[supported value](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete) wherever
appropriate, e.g. 

```html
<label for="name">
  First Name
</label>
<input id="name" type="text" autocomplete="given-name">
```

For fields where `autocomplete` is not appropriate, e.g. due to security, or the field not matching the
specification, the specific field should be ignored.

## Methodology

* All fields which could support `autocomplete` (e.g. text fields)
  are checked. Other fields - like dropdown menus - are ignored.
* The [accessible name](https://www.w3.org/TR/accname-1.2/) of each field is considered. In most cases this
  will be the `<label>` for the field.
* If the name matches a known pattern the field 
  must have an appropriate `autocomplete` value specified.
  For example, an `<input>` with type `text` with a label of 
  "First Name" would be expected to have an autocomplete value 
  of `given-name` or similar.

Note that using `autocomplete="on"` is not sufficient to pass this check, a
specific named autocomplete value must be used. See the
[supported values](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete).

## Troubleshooting

If a field is a false positive, check whether the field has an 
appropriate accessible name (i.e. a `<label>` or `aria-label`).

If the label is incorrect, Silktide may assume that the field 
requires `autocomplete` where it does not. You should fix the 
label to avoid this.

Otherwise, you can simply ignore the specific field.

## More information

* [How to use HTML 5.2 attributes](https://www.w3.org/WAI/WCAG21/Techniques/html/H98)

identify-input-purpose

Avoid opening links in a new tab or window. Where you must do this, include an explanation
in the text of the link.

## Why this matters

Opening links in a new tab or window breaks the back button and can be disorientating for 
novice web users, and the visually impaired. Generally you should avoid opening links in a
new tab or window, but if you have to, you should include text explaining that this will happen.

## How to fix

An explanation must be clear in the accessible text for the link. For example:

```html
<a href="products.html" target="_blank">
    Products (opens in new window)
</a>
```

Or, for an image inside a link:

```html
<a href="products.html" target="_blank">
    <img src="products.jpg" alt="Products (opens in new window)">
</a>
```

Rather than updating all of your links manually to do this, you can add a simple CSS
selector, such as:

```css
a[target="_blank"]:after {
    content: " (opens in new window)";
}
```

Note that doing this with an icon, is not sufficient to pass this check. The text must be
readable by screen readers.

Alternatively you can override the link text for accessible technologies (like screenreaders),
so that the appearance of the link does not change. For example:

```html
<a href="products.html" target="_blank" aria-label="Products (opens in new window)">
    Products
</a>
```

Note that if you do this, the `aria-label` will replace the text content of the link completely,
so it must still make sense in isolation.

## Terminology

Although it is common to say "opens in new window", almost all browsers now use tabs, and
so this terminology is potentially confusing. You may prefer: "opens in new tab".

## Methodology

1. Silktide considers all links on a page with a `target` attribute of `_blank`.
2. For each link, Silktide considers the screen-readable text of the link, which includes:
   * The text content of the link
   * Any `alt` text inside any images inside the link
   * Any `aria-label` or `aria-labelled-by` text
   * The `content` of the pseudo-elements `:before` and `:after`
3. This text is analysed for the presence of common text, including "opens new tab"
    and "opens new window". If the text is not found, the link fails the test.

## Further reading

Generally best practice is to avoid opening links in a new tab or window.  

The W3C provides detailed guidance on 
[when opening a link in a new window may be appropriate](https://www.w3.org/TR/WCAG20-TECHS/G200.html).

link-text-explains-open-in-new-window

When specifying accessible names via `aria-labelledby`, ensure that the 
label elements exist.

## Explanation

Accessible names are required for many parts of a page, including form controls.
One way to accomplish this is to use `aria-labelledby` to specify the ID or IDs of 
other elements which contain a label. For example:

```html
<h2 id="dialog-labell">Important message!</h2>
<dialog aria-labelledby="dialog-label">
```

In this example, the `aria-labelledby` for the `<dialog>` points to an ID of `dialog-label`,
which doesn't exist. The heading it refers to instead has an ID of `dialog-labell`, presumably 
a typo.

## Why this matters

It isn't usually clear when an accessible name is broken, even during user testing.

This check helps to identify where an element clearly intended to have a label, but
that label is missing.

When a label is broken, it may be impossible for a user of assistive technologies
to understand what that element does.

missing-aria-labelled-by

Form controls must be appear sufficiently distinct from their surroundings, so that people 
with visual impairments are still able to clearly see them.    

Either the border or the form control itself must have a 3:1 colour contrast with the surrounding 
area. 

[Learn more about this requirement](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html).

non-text-contrast

Headings in a PDF should follow the sequence Heading 1 > Heading 2 > Heading 3 without skipping intermediate headings.

It is acceptable to 'go back' to previous styles/headings but the sequence should then continue without missing headings.

See [WCAG](https://www.w3.org/TR/WCAG20-TECHS/pdf.html#PDF9)

pdf-headings-order

Bookmarks (also known as outline entries) should be applied to long PDFs to 
provide a hierarchical overview of the document to help aid navigation. 

WCAG guidelines do not specify how many pages are required to be classified as a 
long PDF. Because of this Silktide treats PDFs of 21 or more pages as long. 
This matches [Adobe Acrobat](https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html?trackingid=KACNN#Bookmarks) 
interpretation.  

See [WCAG](https://www.w3.org/TR/WCAG20-TECHS/pdf.html#PDF2) for advice.

pdf-long-document-requires-bookmarks

PDFs should have a default document language set to help render text accurately and help screen readers pronounce words correctly. 
See [WCAG](https://www.w3.org/TR/WCAG20-TECHS/pdf.html#PDF16) for reference.

pdf-missing-default-language

PDF files should have headings.
 See [WCAG](https://www.w3.org/TR/WCAG20-TECHS/pdf.html#PDF9)

pdf-missing-headings

PDFs need to be tagged in a valid reading order for accessibility. See [Adobe's guide](https://helpx.adobe.com/uk/acrobat/using/creating-accessible-pdfs.html#tag_the_pdf) and [WCAG](https://www.w3.org/TR/WCAG20-TECHS/pdf.html#PDF3) for advice.

pdf-must-be-tagged

All PDFs must define a valid title. This must not be confused with the file name. 
See [PDF 18](https://www.w3.org/TR/WCAG20-TECHS/PDF18.html) for details.

pdf-no-title

PDFs need to be machine readable for accessibility software to be able to access them. 
Scanned documents or password protected ones are usually not machine readable.

pdf-not-machine-readable

All PDFs must define a descriptive title. 
See [PDF 18](https://www.w3.org/TR/WCAG20-TECHS/PDF18.html) for details.

Priority	Recommendation	Progress
	Ensure controls clearly indicate when they are selected WCAG 2.2 AA 2.4.11	29.4%
	Ensure focus is not fully obscured WCAG 2.2 AA 2.4.12	99.5%
	Tag all PDFs WCAG 2.0 A 1.3.1	65.2%
	Ensure PDFs are machine readable WCAG 2.0 A 1.1.1	91.3%
	Ensure PDFs have a title WCAG 2.0 A 2.4.2	73.9%

Joseph Rowntree Housing Trust

Accessibility

Accessibility recommendations