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

Hengelo (O.)

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

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

All dialogs (sometimes knows as 'pop up windows') should declare an accessible label that
can be read out by screen readers.

To do this, use `aria-label` to specify a label, or `aria-labelledby` to point to the `id`
of an element that contains text describing the modal, e.g.:

```html
<div role="dialog" aria-labelledby="title">
    <div id="title">
        This is a dialog
    </div>
</div>
```

The above example dialog has a label of `This is a dialog`.

dialog-labels

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

### Not enough contrasting pixels change

The [Success Criterion](https://w3c.github.io/wcag/understanding/focus-appearance.html) specifies a minimum area 
for the contrasting portion of the focus indicator, which is equivalent to a 2 CSS pixel border around the component.

From the requirements:

> "The easiest and most common way to meet this requirement is to use a solid outline around the component. 
> The outline must be at least 2px thick."

In practice, many websites use alternatives to this, such as a thick border along one edge. A problem with 
that approach is it is often dependent upon the length of that one edge, which for text links can vary dynamically.

See [Sara Soueidan](https://www.sarasoueidan.com/blog/focus-indicators/#2.-minimum-contrasting-area) for a good
write-up of this concept.

To comply with this Success Criterion, we recommend adding a 2px border around all edges.

Note an earlier draft of this Success Criterion has a more generous allowance here, which is not the case for the
final version.

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

* [WCAG 2.4.13](https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance.html)
* [Minimum Contrasting Area explained (Sara Soueidan)](https://www.sarasoueidan.com/blog/focus-indicators/#2.-minimum-contrasting-area)

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. 

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

## Testing this manually

* Open the page
* Press the tab key to move focus through elements on the page
* Check that the focus indicator is not fully obscured by anything in front of it

## Comparison with Level AA version

This is the stricter (Level AAA) version of the Level AA check (2.4.11).

The Level AA version only flags issues where the focus indicator is _completely_ obscured, this
version flags issues where the focus indicator is _partly_ obscured.

## 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.

The two most very common solutions are:

1. Avoid the use of fixed elements that could obscure other elements
2. Use the CSS `scroll-margin` property (see [WCAG Technique C43](https://www.w3.org/WAI/WCAG22/Techniques/css/C43))

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).

## Methodology

1. Silktide simulates a keyboard user tabbing through the page
2. Silktide simulates the focused element being vertically scrolled into the center of the page
   (see 'Rationale for scrolling' below)
3. For each element that receives focus, Silktide checks that the focus indicator is not obscured
   by another element on top of it
4. If the focus indicator is obscured, Silktide raises an issue

### Rationale for scrolling

The rationale for point #2 (above) is worth expanding. At different screen sizes, the amount of scrolling
a browser makes between tabs will vary. For example, Chrome will typically avoid scrolling until a
focus element falls outside the current viewport, and then it will adopt the least amount of
scrolling possible to bring the element into view.

This means if you test a page in Silktide, and in a browser with a fractionally different height,
you may experience different elements being obscured or not, especially elements blocked by sticky headers
and footers. Every only a few pixels of difference in screen height can make a huge difference the
further down the page you go.

In all these cases, the use of user-directed vertical scrolling, e.g. via the cursor keys, would permit
the focused element to be seen. Whether that would be necessary would depend on the exact browser and
size of the browser viewport.

Silktide purposely adopts a generous frame here, to avoid flagging issues which might only affect the
exact screen size that it tested. In our testing, when we didn't do this, the number of subjectively false
positives could be very high, and extremely confusing, as they would not replicate during manual testing on
anything but the exact same browser size.

Essentially, Silktide chooses not to flag issues which _could_ affect some very particular screen sizes
_inconsistently_, but it will flag issues that should affect _all_ screen sizes consistently.

The W3C does not specify how to test this Success Criterion.

### Simulating conditional modals

Silktide adopts additional behavior to simulate the use of dialog modals that may be opened by user
behavior after a page loads (i.e. modals that don't automatically open when a page loads).

If a non-opened modal is detected, Silktide assumes that _elements outside the modal cannot be focused_.
This is not guaranteed, but it is impossible for Silktide to predict the behavior of a modal that has not
yet been opened, and this is much more accurate than assuming that the modal does not constrain focus.

As a result, a modal which is incorrectly programmed (i.e. doesn't constrain focus) may not be detected
as obscuring focus behind it, if the modal is not opened by default.

## Further reading

* [WCAG 2.4.12](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-enhanced)
* [WCAG Technique C43 - Using CSS margin and scroll-margin to un-obscure content](https://www.w3.org/WAI/WCAG22/Techniques/css/C43)

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

## Testing this manually

* Open the page
* Press the tab key to move focus through elements on the page
* Check that the focus indicator is not fully obscured by anything in front of it

## Comparison with Level AAA version

This is the less strict (Level AA) version of the Level AAA check (2.4.12).

This Level AA version only flags issues where the focus indicator is _completely_ obscured, the
Level AAA version flags issues where the focus indicator is _partly_ obscured.

## 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.

The two most very common solutions are:

1. Avoid the use of fixed elements that could obscure other elements
2. Use the CSS `scroll-margin` property (see [WCAG Technique C43](https://www.w3.org/WAI/WCAG22/Techniques/css/C43)) 

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).

## Methodology

1. Silktide simulates a keyboard user tabbing through the page
2. Silktide simulates the focused element being vertically scrolled into the center of the page
   (see 'Rationale for scrolling' below)
3. For each element that receives focus, Silktide checks that the focus indicator is not obscured
   by another element on top of it
4. If the focus indicator is obscured, Silktide raises an issue

### Rationale for scrolling

The rationale for point #2 (above) is worth expanding. At different screen sizes, the amount of scrolling 
a browser makes between tabs will vary. For example, Chrome will typically avoid scrolling until a
focus element falls outside the current viewport, and then it will adopt the least amount of 
scrolling possible to bring the element into view.

This means if you test a page in Silktide, and in a browser with a fractionally different height, 
you may experience different elements being obscured or not, especially elements blocked by sticky headers 
and footers. Every only a few pixels of difference in screen height can make a huge difference the 
further down the page you go.

In all these cases, the use of user-directed vertical scrolling, e.g. via the cursor keys, would permit 
the focused element to be seen. Whether that would be necessary would depend on the exact browser and
size of the browser viewport.

Silktide purposely adopts a generous frame here, to avoid flagging issues which might only affect the 
exact screen size that it tested. In our testing, when we didn't do this, the number of subjectively false
positives could be very high, and extremely confusing, as they would not replicate during manual testing on
anything but the exact same browser size.

Essentially, Silktide chooses not to flag issues which _could_ affect some very particular screen sizes 
_inconsistently_, but it will flag issues that should affect _all_ screen sizes consistently.

The W3C does not specify how to test this Success Criterion.

### Simulating conditional modals

Silktide adopts additional behavior to simulate the use of dialog modals that may be opened by user
behavior after a page loads (i.e. modals that don't automatically open when a page loads).

If a non-opened modal is detected, Silktide assumes that _elements outside the modal cannot be focused_.
This is not guaranteed, but it is impossible for Silktide to predict the behavior of a modal that has not
yet been opened, and this is much more accurate than assuming that the modal does not constrain focus.

As a result, a modal which is incorrectly programmed (i.e. doesn't constrain focus) may not be detected 
as obscuring focus behind it, if the modal is not opened by default.

## Further reading

* [WCAG 2.4.11](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum)
* [WCAG Technique C43 - Using CSS margin and scroll-margin to un-obscure content](https://www.w3.org/WAI/WCAG22/Techniques/css/C43)

ensure-focus-is-not-obscured-minimum

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

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

This is default behavior for all standard web controls, and so if this issue is appearing
it is because this default behavior has been disabled. Or alternatively, if you have written
your own custom controls, these will need styling to support focus states.

## How to fix

Links and form controls typically define an `outline` CSS style, which ensures
they are highlighted automatically, for example:

```css
input:focus (outline: 2px solid red);
``` 

If you choose to override or disable the default `outline`, you should specify an accessible 
alternative, such as a border or background color.

### 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.

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

* [WCAG 2.4.7](https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html)

ensure-focus-is-visible

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

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

form-control-labels

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

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

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

Form controls must 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. 

## Methodology

* All `<input>`, `<textarea>`, and `<select>` elements are checked.
* For `<input>` elements, these types are ignored as their
  appearance is controlled by the browser or operating system:
  `checkbox`, `radio`, `submit`, `reset`, `image`, `hidden`, `file`. 
* The flattened background color of the control is determined. This is the color of the
  control itself, combined with any parent elements if the control is transparent.
* If the control has a border or outline:
  * The flattened background color of each edge is determined. 
    This is the color of the edge itself, combined with any parent elements
    if the edge is transparent.
  * If any edge has sufficient contrast with the flattened background color of the control, 
    the control is considered to have sufficient contrast.
* If the control does not have a border or outline:
  * The flattened background color of the surrounding 
    area is determined. This is the color of the first control's parent element which is at least 
    one pixel larger around the element in every dimension, i.e. above, below, left, and right.
  * If the background color of the element has sufficient contrast with surrounding area color
    the control is considered to have sufficient contrast.

## Troubleshooting

There are some limitations to the contrast checker:

* The use of drop shadows, glowing effects, gradients, and other complex effects 
  mean there is no one clear color to determine the contrast ratio against. 
  In these cases, the contrast ratio cannot currently be determined.
* It is possible for an element to be positioned over multiple elements, e.g. via
  `position: absolute` or `position: fixed`. In this case, the contrast ratio cannot 
  currently be determined.

## Further reading

* [WCAG 1.4.11](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html)

non-text-contrast

wcag-22.score

wcag-22-a.score

wcag-22-aa.score

wcag-22-aaa.score

website.pages

website.documents

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

Ensure that PDF documents specify a default language, so that assistive technologies can accurately 
interpret their contents.

## What this means

Specifying a default language for a PDF means setting the primary language in which the document's content is written. 
This setting informs users and assistive technologies about the language the content is presented in, aiding in 
proper interpretation and pronunciation.

## Why it matters

1. **Accessibility**: Screen readers rely on language settings to provide correct pronunciation, making it essential for non-native speakers and individuals using text-to-speech software.
2. **User Experience**: Specifying the language helps in providing a better reading experience as it enables features like spell check and grammar tools to function correctly.
3. **Global Compliance**: Setting a default language is a requirement under various international accessibility standards, like the Web Content Accessibility Guidelines (WCAG).

## How to fix

1. **Check Document Properties**: Open the document properties in your PDF editor and navigate to the language setting.
2. **Set the Default Language**: Choose the appropriate language from the list provided or enter it manually if it's not listed.

## Testing Methodology

Silktide analyzes the document properties of the PDF to verify if a default language is specified.

### Limitations
- **Language Accuracy**: While Silktide can detect the presence of a language setting, it does not assess the accuracy of the language in relation to the document's content.
- **Multilingual Documents**: For documents containing multiple languages, Silktide might only detect the primary language set in the document properties.

## Further Reading

- [WCAG PDF 16](https://www.w3.org/TR/WCAG20-TECHS/pdf.html#PDF16)
- [Setting Language in PDF Documents](https://www.adobe.com/accessibility/pdf/pdf-accessibility-overview.html)
- [Understanding WCAG: Language of Page](https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-doc-lang-id.html)

pdf-missing-default-language

Ensure that PDF documents specifies headings for accessibility.

## What this means

Specifying headings in a PDF involves clearly defining tagged heading elements within 
the document. These headings are used to structure the content, similar to how headings 
are used in web content (like HTML). 

## Why it matters

1. **Accessibility**: Headings are crucial for screen readers and other assistive technologies. They allow users with visual impairments to navigate the document more easily.
2. **Document Structure**: Clearly defined headings help in organizing the content, making it more understandable and navigable for all users.
3. **Search Efficiency**: Proper headings improve the document's searchability, enabling users to find information more quickly.

## How to fix

1. **Use Styles in Document Creation**: When creating a document, use heading styles (like Heading 1, Heading 2, etc.) in your word processor before converting it to a PDF.
2. **Edit Existing PDFs**: If your PDF is already created, use a PDF editor to add or modify heading tags. Ensure that the headings are in a logical hierarchical order.

## Testing Methodology

Silktide flags PDFs that don't contain a single tagged heading.

## Further Reading

- [WCAG PDF9](https://www.w3.org/TR/WCAG20-TECHS/pdf.html#PDF9)
- [Creating Accessible PDFs](https://www.adobe.com/accessibility/pdf/pdf-accessibility-overview.html)
- [PDF Accessibility - Defining PDF Accessibility](https://www.webaim.org/techniques/acrobat/)

pdf-missing-headings

PDF documents must be tagged to ensure accessibility and compliance with digital standards.

## What this means

Tagging in a PDF involves adding hidden metadata that outlines the structure and content of the document. These tags function similarly to HTML tags, describing elements like headings, paragraphs, lists, and tables. They are crucial for screen readers and other assistive technologies to interpret the content correctly.

## Why it matters

1. **Accessibility**: Tagging makes PDFs accessible to individuals with disabilities, allowing assistive technologies to read and navigate the document effectively.
2. **Legal Compliance**: Various laws and regulations require digital content, including PDFs, to be accessible. Failure to comply can lead to legal complications.
3. **Usability**: Tagged PDFs are more user-friendly, providing better navigation and search capabilities for all users.

## How to fix

1. **Use Tag-enabled PDF Creators**: Create or convert documents using software that supports tagging, like Adobe Acrobat or Microsoft Word.
2. **Manually Add Tags**: If your PDF isn't tagged, use a PDF editor's accessibility tools to add tags. This includes setting a logical reading order and adding alternative text for images.
3. **Consult Guidelines**: Follow best practices outlined in WCAG or similar guidelines for effective tagging.

## Testing Methodology

Silktide looks at the PDF and flags it if it doesn't contain tags.

## Further Reading

- [Adobe's Guide to PDF Accessibility](https://www.adobe.com/accessibility/pdf/pdf-accessibility-overview.html)

Priority	Recommendation	Progress
	Ensure focus is not fully obscured WCAG 2.2 AA 2.4.11	0%
	Ensure controls change appearance when they are selected WCAG 2.0 AA 2.4.7	10.4%
	Ensure controls clearly indicate when they are selected WCAG 2.2 AAA 2.4.13	45%
	Avoid linking to anchors that do not exist WCAG 2.0 A 2.4.1	16.6%
	Ensure lists are marked up correctly WCAG 2.0 A 4.1.1	33.3%

Hengelo (O.)

Accessibility

WCAG Levels

Recommendations

The best free accessibility checker