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

February 2023

March 2023

April 2023

May 2023

July 2023

August 2023

September 2023

October 2023

November 2023

December 2023

January 2024

February 2024

March 2024

April 2024

May 2024

June 2024

July 2024

August 2024

September 2024

October 2024

November 2024

December 2024

January 2025

February 2025

March 2025

April 2025

May 2025

June 2025

July 2025

August 2025

September 2025

October 2025

November 2025

December 2025

Bakkavör

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 WCAG AA, the colour of text must sufficiently contrast with
its background color, so that people with moderate 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 4.5:1 for body text, and 3:1 for large text.

A much more demanding version of this check (1.4.6) exists for WCAG AAA. Ignoring an issue in this check 
will also ignore it in that check, and vice versa.

aa-text-contrast

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

All table headers should define a valid `scope` attribute, which tells assistive technologies
what the header refers to.

For example:

```html
<table>
    <thead>
    <tr>
        <th scope="col">Name</th>
        <th scope="col">Age</th>
    </tr>
    </thead>
    <tbody>
    <tr>
        <td>Bob</td>
        <td>35</td>
    </tr>
    <tr>
        <td>Sue</td>
        <td>45</td>
    </tr>
    </tbody>
</table>
```

In this example, the `scope` attribute indicates the two `<th>` cells are column 
headers, which allows assistive technologies to read out those headers alongside
each `<td>` cell. 

Without this information, the structure of the table is only apparent to people
who are able to see it.

add-scope-attribute-to-table-headers

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

Two adjacent links should not point to the same destination. You almost always want to combine the 
two links.

For example, it is quite common to link an image and text together like this:

```html
<a href="news.html">
    <img src="photo.jpg" alt="" />
</a>
<a href="news.html">
    News
</a>
``` 

These adjacent links should be combined like so:

```html
<a href="news.html">
    <img src="photo.jpg" alt="" />
    News
</a>
``` 

Links to `#` are ignored, as these are nearly always placeholders for JavaScript, e.g.:

```html
<a href="#" onclick="approve()">
    OK
</a>
<a href="#" onclick="reject()">
    Cancel
</a>
```

# Justification

Many users of assistive technology are only able to experience content sequentially - that is, they must
step through each part of the page, one part at a time. Often this is a slow process, potentially 
hampered by a physical impediment.

Stepping through redundant links is time consuming; for example users of a screen reader must 
hear each link read aloud in turn. 

This also simplifies your code. 

# Methodology

1. Find all links (`<a>` tags) on the page.
2. Ignore links pointing to `#`, as these are usually placeholders for JavaScript.
3. Flag links which are (a) separated only by whitespace and (b) which point to the 
   same absolute URL.  

# Learn more

Read about [Technique H2](https://www.w3.org/TR/WCAG20-TECHS/H2) on how to combine
an adjacent image and texts links.

duplicate-adjacent-link

All `id` attributes on a page must be unique, or accessible technologies used by the page 
can stop working.

## Example

The duplicate `id` here makes it unclear which label belongs to which input field:

```html
<label for="name">Your name</label>
<input id="name">

<label for="name">Company name</label>
<input id="name">
```

As a result, accessible technologies like screen readers can fail to read out the 
correct text, or may read out no text at all.

Similar issues can occur when using `aria-labelledby` and `aria-describedby`.

## How to fix

Ensure all `id` attributes on a page are unique. 

## More information

See [Technique H93](https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H93) 
for more information.

duplicate-id

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 interactive components on a page, such as buttons or menus, should be far enough apart 
from other interactive areas, to avoid them being used by mistake. 

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

## How to fix

* Ensure all interactive elements are at least 24 CSS pixels wide and tall
* OR ensure there is at least 24 CSS pixels (minus the width and height of the element)
  between each interactive element

## 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 not normally visible, it is ignored. This includes elements which
   are positioned offscreen or cropped (e.g. for 'screen-reader only' text).
3. If an element is larger than 24 CSS pixels in both dimensions, it passes.
4. Otherwise, the element is compared to all other elements on the page.
5. The minimum horizontal gap between the element is calculated as 24 CSS pixels,  
   minus the width of the element.
6. The minimum vertical gap between the element is calculated as 24 CSS pixels,  
   minus the height of the element.
7. If another element falls within the minimum horizontal or vertical gap, the 
   element fails, unless both are links that point to the same place.

## Further reading

* [Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html)
* [Technique C42 - Using min-height and min-width to ensure sufficient target spacing](https://www.w3.org/WAI/WCAG22/Techniques/css/C42)

ensure-minimum-target-size

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 preceded 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

When viewed on small screens (like mobile phones) content should be large enough to 
read without being zoomed-into and scrolled in two dimensions.

WCAG 2.1 specifically requires this for:

+ Vertical scrolling content at a width equivalent to 320 CSS pixels
+ Horizontal scrolling content at a height equivalent to 256 CSS pixels

This issue almost always indicates that the webpage has not been designed
to work on mobile devices at all.

extreme-zoom-scrolling

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

When an image is the only content of a link, it should specify alternative text, 
via an `alt` attribute. The alternative text should describe the purpose of the link.

Without this, some users will be unable to determine what a link does, for example anyone 
using a screen reader.

To fix this, simply add an `alt` attribute to the image inside the link, e.g.:

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

img-in-link-missing-alt

Links must be appear visually distinct from regular text. A common mistake is to make links
only differ subtly in color. Users with visual impairments cannot see these links.   

There are two ways to comply with this requirement:

1. You can make links appear differently from regular text without relying on color alone.
   For example, you can add an underline to your links. This makes links easy to identify, even
   to people who cannot see color at all.
2. You can make links a color which is very different from the surrounding text (a 3:1 ratio), 
   AND ensure that when the link is selected with the keyboard or mouse that it appears   
   differently from regular text without relying on color alone.

Unless you have disabled the `outline` CSS style, links will automatically appear visually distinct
when selected with the keyboard.

link-contrast

The purpose of a link should be clear from the text inside the link. Links like "learn more" are
not helpful to users with assistive technology.

Links should also avoid redundantly saying that they are links, e.g. "link to page" as screen
readers will read these out with the word "link" added, e.g. "link link to page".

Exceptions to these rules are allowed where the purpose of a link would be ambiguous to users 
in general.

link-purpose-a

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

Do not link to an anchor on the page that does not exist. For example:
linking to `#content` without a valid destination such as `<body id="content"></body>`.

A common web design pattern is to use a named anchor to show an element via JavaScript, e.g.

```html
<a href="#foo" onclick="$('.bar').toggle();">Click me</a>
<div class="bar">
    This is some content.
</div>
``` 

In these cases, the anchor (`#foo`) should point to the `id` of the hidden element:

```html
<a href="#foo" onclick="$('#foo').toggle();">Click me</a>
<div id="foo">
    This is some content.
</div>
```

This way the semantic intent of the link is preserved, even without JavaScript. 
Note that doing so may require modification to your script, to prevent automatic 
scrolling to the named anchor.

linking-to-anchor-on-page-that-does-not-exist

Lists of related items should be written [semantically](https://html.com/semantic-markup/) as a 
list.

Usually this means rewriting these to use the `<ul>` or `<ol>` tags.

This allows assistive technologies to more easily navigate from item to
item, or past entire groups of links if the user wants to. 

## Examples 

### Navigation

This navigation:

```html
<a href="/about">About us</a>
<a href="/products">Products</a>
<a href="/contact">Contact us</a>
```

Should be rewritten as a list:

```html
<ul>
  <li><a href="/about">About us</a></li>
  <li><a href="/products">Products</a></li>
  <li><a href="/contact">Contact us</a></li>
</ul>
```

### Tables for content

This single-column table is redundant. There is no
value in placing the content in a table, which makes
it harder for screen reader users to interpret and interact
with.

```html
<table>
  <tr>
    <td>
      Banana
    </td>
  </tr>
  <tr>
    <td>
      Apple
    </td>
  </tr>
  <tr>
    <td>
      Pear
    </td>
  </tr>
</table>
```

Should be rewritten as a list:

```html
<ul>
  <li>Banana</li>
  <li>Apple</li>
  <li>Pear</li>
</ul>
```

## Justification

Users of assistive technologies, like screen readers, can skip an entire
list in one step. In some cases, they can even search inside a list. 

These aids are not available where links are written outside a list. 
Failing to use lists correctly can force users to have to step through
hundreds of items one at a time.

## Methodology

1. Any single-column tables are automatically considered 
   redundant lists. 
2. For non-table elements, recursively work down the page looking inside
   each element for links separated by minimal amounts of non-link text. 
   If the non-link text is below 30 characters 
   in length, we assume we're inside content that should be a list.
   Some exceptions are made, e.g. the presence of an `<hr>` would break
   out of the list.

## More information

See [Technique
H48](https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H48) for
details.

mark-navigation-section-as-list

Images should specify appropriate
[alternative text](https://help.silktide.com/en/articles/8020957-alternative-text), 
where appropriate.

Alternative text is text that is used in place of an image if it cannot
be seen. This is important for users who are blind or partially sighted, 
who may have the page read to them by a screen-reader. Without alternative 
text, they will not know what the image is, or what it is for.

## How to fix this issue 

In most cases, you can fix this issue by adding alternative text to the media
in your Content Management System (CMS).

If you need to do this in code, you can alternative text to an image using 
the `alt` attribute. For example: 

```html
<img src="apple.png" alt="A red apple">
```

Alternative text should be descriptive and useful. We recommend you read 
[this comprehensive guide to writing alternative text](https://webaim.org/techniques/alttext/)
by WebAIM.

It is not always appropriate to provide alternative text. For example, if an
image is purely decorative - it adds nothing to the content of the page - then
it is better to omit the alternative text entirely. This is because screen-reader
users will have to listen to the alternative text, which can be annoying if it
is not useful, or highly repetitive.

To specify that an image is decorative, use an empty `alt` attribute, e.g.:

```html
<img src="decorative-image.png" alt="">
```

## Methodology

This check tests if the `alt` attribute is present on an image. If it is not, 
then the check fails.

Some images are excluded from this check:

1. **Images without a `src` attribute.** This is because they are
   not visible to users, and therefore do not need alternative text.
2. **Images which are 1px in width or height.** This is because they are only
   used for tracking pixels, or (rarely) layout purposes, and do not need 
   alternative text.
3. **Images which are hidden from screen readers using the `aria-hidden` attribute.**
   This is because they are not accessible to screen readers, and therefore would not 
   use their alternative text.

## More information

The W3C also provide more information on how to satisfy this check in 
[Technique H37](https://www.w3.org/TR/WCAG20-TECHS/H37).

missing-alt

When using accessible descriptions (`aria-describedby`), ensure that the 
descriptions exist.

## Explanation

ARIA descriptions are commonly used to add supplementary information to 
elements in a page, especially form controls. For example:

```html
<input type="email" aria-describedby="email-help">
<p id="email-helpp">Enter your work email address</p>
```

In this example, the `aria-describedby` for the field points to an ID of `email-help`,
which doesn't exist. The paragraph it refers to instead has an ID of `email-helpp`, presumably 
a typo.

## Why this matters

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

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

When a description is broken, key information about that element may be omitted from 
assistive technologies.

missing-aria-described-by

Every page should have a clearly defined heading, known as a "H1" (Heading 1).

A `H1` is the main heading of the page. It helps accessibility by allowing uses to
skip to the main content of the page. It helps all users identify what the page is about. 
It helps SEO by giving special emphasis to the topic of the page.

It is not enough to simply include large text. Headings must be coded 
[semantically](https://html.com/semantic-markup/) as `<h1>` tags, like so:

```html
<h1>This is a heading</h1>
```

Note that headings must contain some machine readable text to be considered valid. 
For example, this heading is not valid:

```html
<h1>
    <img src="company-logo.png">
</h1>
``` 

But with the addition of `alt` text, this heading is valid:

```html
<h1>
    <img src="company-logo.png" alt="About Company Inc.">
</h1>
``` 

Generally we recommend you just use plain text for your headings.
See [Technique H42](https://www.w3.org/TR/WCAG20-TECHS/H42) for more details.

missing-h1

Labels with a `for` attribute should point to the unique ID of a [labelable
control](https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories#Form_labelable)
that is used within the document.

## Why this matters

Form controls must define labels. This allows users of assistive technologies, 
such as screen readers, to know what the purpose of a form control is.

If a label uses an invalid `for` attribute (i.e. one which is missing, or duplicated,
or points to something that is not labelable), that field will not be usable by assistive 
technologies.

## How to fix

The `<label>` element should specify a `for` attribute that points to a
labelable control element. This error can occur if you point to a
non-labelable component, or if you don't point to a component that exists.
See [Technique H44](https://www.w3.org/WAI/WCAG21/Techniques/html/H44).

Example:

```html
<label for="name">Name</label>
<input type="text" id="name" />
```

Alternatively, if you need to point to a component that doesn't accept a label 
(e.g. a `<div>`), consider using the `aria-labelledby` attribute instead. 
See [Technique ARIA16](https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA16).

Example:

```html
<h2 id="price-label">Minimum price</h2>
<div role="slider" aria-labelledby="price-label"></div>
```

## Further reading

* [WCAG 1.3.1](https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html)

remove-for-attribute-which-does-not-exist

Webpages should provide a way to skip to the main content of the page. There are 
several ways to accomplish this.

The most common solution is a "Skip to content" link:

```html
<a href="#main">Skip to main content</a>
...
<div id="main">
<h1>Welcome to this page</h1>
```

This link is usually hidden from users unless selected, so it doesn't need to compromise the look of 
your page.

Alternatively, you can use the `<main>` HTML landmark:

```html
<main>
<h1>Welcome to this page</h1>
``` 

or an ARIA role of `main`:

```html
<div role="main">
<h1>Welcome to this page</h1>
``` 

Generally best practice is to combine these approaches, using `<main>` landmark with a link pointing to it:

```html
<a href="#main">Skip to main content</a>
...
<main id="main">
<h1>Welcome to this page</h1>
```

This approach will be most widely supported by screen readers and understood by the highest number of users.

# Justification

Many users of assistive technology are only able to experience content sequentially - that is, they must
step through each part of the page, one part at a time. Often this is a slow process, potentially 
hampered by a physical impediment.

Most web pages have a header containing branding and navigation on every page. Stepping through 
this repetitive part of the page can be hugely frustrating for users of assistive technology. For example, 
a blind user may have to listen to hundreds of navigation links before they can reach the content on a page.

Adding a means to skip directly to the page content massively enhances the experience for these users.

Skip to content links do not need to be visible to everyone. A common implementation means they are only 
experienced by users via the tab key or other assistive technology 
(see [skipping to navigation links](https://webaim.org/techniques/skipnav/) from WebAIM). 

# Methodology

It is not sufficient to include a "skip to content" link. The link must work, and it must appear early
enough in the page to be useful.

* If the page has less than 500 visible characters, it does not require a "skip to content" link.
* If the page has a main landmark (e.g. `<main>` or `role="main"`) it does not require a "skip to content" link.
* Silktide looks for a link with a fragment (e.g. `#main`) pointing to a lower part of the page. The link 
  must not be adjacent to other text nodes. 
* The fragment must point to an ID that exists, or this check will raise an error.
* The link must appear before 500 visible characters of text in the page, or this check will raise an error.

The text inside the link is not considered, as this test must support a wide range of languages.

# Learn more

More about [skipping to navigation links](https://webaim.org/techniques/skipnav/) from WebAIM and 
see [W3C's recommended technique](https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G1).

skip-to-content

When viewed on small screens (like mobile phones) content must fit without 
requiring scrolling in two dimensions.

WCAG 2.1 specifically requires this for:

+ Vertical scrolling content at a width equivalent to 320 CSS pixels
+ Horizontal scrolling content at a height equivalent to 256 CSS pixels

Except for parts of the content which require two-dimensional layout for usage or meaning,
such as a maps application.

two-dimensional-scrolling

wcag-22.score

wcag-22-a.score

wcag-22-aa.score

wcag-22-aaa.score

website.pages

website.documents

All frames must define a readable title, which briefly described the contents of that frame.

Note that this is not the same as a `<title>` tag inside the iframe, which is insufficient.
You must provide a meaningful description for the frame using the `title` attribute.

Examples:

```html
<iframe title="Advertisement" src="ad.html">
```

```html
<frame title="Advertisement" src="ad.html">
```

# Why this matters

Accessible technologies such as screen readers rely on the `title` attribute to list
the frames on a given page. 

Without a title, it is impossible to know what the frame contains, and the user must
navigate inside it, and explore the contents of the frame to figure this out.

Often iframes are used for technologies like banner ads, videos, or chat widgets. The 
absence of a `title` makes these areas of the page much harder to identify, understand, 
or use.

# How titles are tested

Frames which are not presented to screen readers are ignored. This includes invisible
frames, and frames marked with `aria-hidden`.

A `title` attribute must contain meaningful text, e.g. numbers / letters, to be considered
valid. A title containing just spaces, or non-readable text (e.g. an emoji) will
be flagged as invalid.

# More information

Learn about [Technique H64](https://www.w3.org/WAI/WCAG21/Techniques/html/H64)
as part of [SC 2.4.1 - Bypass Blocks](https://www.w3.org/WAI/WCAG21/Understanding/bypass-blocks).

has-frame-title

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

Lists (e.g., `<ul>` or `<ol>`) should only contain list items (`<li>`) as a direct descendant 
to ensure that screen readers can accurately report the amount of items contained in the list. 

## Example

In the following example, some screen readers would say this list has two items, instead of 
four: 

```html
<ul>
    <div class="some_class">
        <li>Example 1</li>
    </div>
    <div class="some_other_class">
        <li>Example 2</li>
        <li>Example 3</li>
        <li>Example 4</li>
    </div>
</ul>
```

To fix this, you would need to remove the `<div class="some_class">` and 
`<div class="some_other_class>` elements and ensure only `<li>` list items remain.

## Further reading

The [formal specification for the list element](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ul)
shows what is and is not permitted inside an `<ul>` and `<ol>`.

See [Technique H88](https://www.w3.org/TR/WCAG20-TECHS/H88.html) for more information.

list-not-following-semantics

An `<img>` element inside a link must not specify alternative text that duplicates the
content of a text link inside or beside it.

For example, this code should be avoided:

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

Accessible technologies will tend to see this as "Apple Apple". The correct behaviour is to
specify either a null (empty) `alt` attribute:

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

or to hide the image via `aria-hidden`:

```html
<a href="/apple">
    <img src="apple.png" aria-hidden="true">
    Apple
</a>
```

# Learn more

Read about [Technique H2](https://www.w3.org/TR/WCAG20-TECHS/H2) on how to combine
an adjacent image and texts links. 

See the [WAI Tutorial on decorative images](https://www.w3.org/WAI/tutorials/images/decorative/).

img-duplicate-alt

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

Radio buttons or check boxes with the same name attribute must be contained
within a fieldset element.

contain-radio-or-checkbox-with-same-name

People using screen readers are not able to see the layout of a form. To make forms
accessible, they must define explicit text labels for each form control. 

Usually the best solution is to use a `<label>` element. The label may be linked to 
by the form control:

```html
<label for="name">Full name</label>
<input type="name" id="name">
```

or the `<label>` can be wrapped around the form control:

```html
<label>
    Full name <input type="name">
</label>
```

Buttons are different, as their labels are specified by the code for the button, e.g.

```html
<input type="submit" value="Send message">
<button>Send message</button>
```

Alternatively ARIA attributes, such as `aria-label` may be used, but this information
will not be conveyed to visual users. For more information, see [W3C's guide to labeling controls](https://www.w3.org/WAI/tutorials/forms/labels/).

Hidden input fields (`<input type="hidden">`) do not require labels.
Note that the `placeholder` attribute 
[should not be used as an alternative to a label](https://www.w3.org/TR/html/sec-forms.html#the-placeholder-attribute),
nor should the `title` attribute.

## Custom roles

Note that this check considers the underlying accessible role of an element, which can be 
different from the tag itself.

For example, this `<div>` has a `role` of `button`, and so is expected to have a label, like
a button would.

```html
<div role="button"></div>
```

Priority	Recommendation	Progress
	Allow users to quickly skip to content WCAG 2.0 A 2.4.1	0%
	Identify the purpose of fields programmatically WCAG 2.1 AA 1.3.5	0%
	Ensure links explain their purpose WCAG 2.0 A 2.4.4	0%
	Ensure interactive components are far enough apart WCAG 2.2 AA 2.5.8	31.2%
	Ensure links are distinguished by more than just color WCAG 2.0 A 1.4.1	33%

Bakkavör

Accessibility

WCAG Levels

Recommendations

The best free accessibility checker