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

January 2026

Aukra

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

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

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

Forms should always contain a submit button, otherwise some people using
accessible technologies may not be able to submit the form.

Submit buttons are `<input>` elements with a type attribute of `submit` or
`image`, or `<button>` elements with type `submit`.

## Rationale 

Many users expect to be able to press enter in a form to submit it. However,
this is not always possible.

Users of some assistive technologies may (depending on the technology) only
be able to press a button to submit the form. In the absence of a submit
button, the user may not be able to submit the form.

In addition, the absence of a submit button suggests that the form may 
provide an automatic 'change of context', i.e. major change to the user 
interface without the user choosing to do so. This can be highly disorientating
to some users.

## Methodology

* All `<form>` elements on the page are tested separately.
* Check whether the <form> contains any of the following elements, and that the elements are visible
  when the page first loads:
  * `<input>`
  * `<textarea>`
  * `<checkbox>`
  * `<select>`
  * `<button>`
* If the form contains any of the above elements, then it is considered to
  need a submit button. If a submit button is missing, then a failure is reported.

### Field visibility check

The check for field visibility (above) is designed to ignore forms which perform functions not normally
associated with user interaction, such as tracking code, or ASPX forms which wrap every page 
but which don't contain any interactive elements. These are common potential false positives.

A trade-off here is that some forms may be invisible when a page loads, and later revealed to
a user following some interaction. If these are missing a submit button, Silktide will not detect them.
In practice, this false negative is far less likely than the false positive this prevents. 

## Further reading

* [WCAG 3.2.2 - On Input](https://www.w3.org/WAI/WCAG22/Understanding/on-input.html)
* [Technique H32](https://www.w3.org/TR/WCAG20-TECHS/H32.html)

form-submit-required

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

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

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

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

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

wcag-22.score

wcag-22-a.score

wcag-22-aa.score

wcag-22-aaa.score

website.pages

website.documents

Ensure each PDF document has a formally defined title.

## What this means

A PDF title, typically found in the document properties, acts as the official name of the document. This title is used by screen readers and other assistive technologies to provide a clear understanding of the document's content at the outset. It's different from any title or heading text that might appear within the content of the PDF itself.

## Why it matters

1. **Accessibility**: Screen reader users often hear the document title first when they open a PDF. A clear, descriptive title helps them understand what the document is about.
2. **Searchability and Organization**: A proper title makes it easier to search for and organize documents on a computer or network.

## How to fix

1. **Set the Title in Document Properties**: In your PDF editor, access the document properties section and ensure there is a title that accurately reflects the content of the PDF.
2. **Use Descriptive Titles**: Avoid vague titles. Instead, choose titles that clearly and concisely convey the subject or purpose of the document.

## Testing Methodology

Silktide checks the document properties of a PDF to verify that a title is 
specified and not empty.

### Limitations
- **Title Relevance**: While Silktide can detect the presence of a title, it does not evaluate the title's relevance or accuracy in representing the document's content.

## Further Reading

- [WCAG - PDF 18](https://www.w3.org/TR/WCAG20-TECHS/PDF18.html)
- [Setting Titles in PDF Documents](https://www.adobe.com/accessibility/pdf/pdf-accessibility-overview.html)

pdf-no-title

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

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

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

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

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

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)

Priority	Recommendation	Progress
	Fix missing ARIA label IDs WCAG 2.0 A 1.3.1	0%
	Allow users to quickly skip to content WCAG 2.0 A 2.4.1	37.5%
	Ensure interactive components are far enough apart WCAG 2.2 AA 2.5.8	40%
	Ensure links explain they open in a new tab WCAG 2.0 AAA 3.2.5	13.1%
	Ensure links are distinguished by more than just color WCAG 2.0 A 1.4.1	97.5%

Aukra

Accessibility

WCAG Levels

Recommendations

The best free accessibility checker