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

February 2026

Zundert

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

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

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

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

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

Ensure the `lang` attribute is correctly specified, i.e. it matches a known language code.

See the specification for [valid language codes](http://www.rfc-editor.org/rfc/bcp/bcp47.txt).

language-attribute-not-well-formed-for-parts

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

Ensures that headings in PDF documents follow a logical hierarchical order for accessibility.

## What this means

Headings in a PDF should be arranged in a logical sequence, much like a table of contents in a book. This means using a consistent hierarchy of heading levels (like Heading 1 for main titles, Heading 2 for subsections, etc.). Headings should not skip levels abruptly (e.g., jumping from Heading 1 directly to Heading 3).

## Why it matters

1. **Accessibility**: Screen readers rely on a logical heading structure to navigate content, making it essential for users with visual impairments.
2. **Readability and Navigation**: A well-structured document with logically ordered headings enhances readability and allows all users to navigate the content more efficiently.
3. **Consistency and Professionalism**: Logical heading order reflects a professional approach to document creation and helps maintain consistency across documents.

## How to fix

1. **Review Heading Levels**: Check your document to ensure that headings follow a sequential order without skipping levels.
2. **Modify Headings**: If any headings are out of order, adjust them using your PDF editing tool to align with the logical structure.

## Testing Methodology

Silktide's checks your PDF to identify the sequence of headings. It flags PDFs where the heading order is not 
hierarchical (e.g., a Heading 3 directly following a Heading 1).

Headings in a PDF should follow the sequence Heading 1 > Heading 2 > Heading 3 without skipping intermediate headings.
It is acceptable to 'go back' to previous styles/headings but the sequence should then continue without missing headings.

### Limitations
- **Contextual Analysis**: Silktide might not fully grasp the context behind the document's structure, so manual review is recommended for complex documents.
- **Styling Variations**: Variations in styling that are not properly tagged might not be detected accurately.

## Further Reading

- [Understanding WCAG: Headings and Labels](https://www.w3.org/WAI/WCAG21/Understanding/headings-and-labels.html)
- [How to Organize PDF Content with Accessible Headings](https://www.adobe.com/accessibility/pdf/pdf-accessibility-overview.html)

pdf-headings-order

Ensure that long PDF documents incorporate bookmarks to facilitate easy navigation.

## What this means

In the context of PDFs, bookmarks are navigational tools that act like an interactive table of contents. 
They allow users to quickly jump to specific sections, chapters, or points of interest within the document. 
This feature is particularly important in longer PDFs, where scrolling through the entire document to find 
specific information can be time-consuming and inefficient.

## Why it matters

1. **Accessibility**: For users with disabilities, especially those using screen readers, bookmarks provide a way to navigate through the document without having to linearly read through all the content.
2. **User Convenience**: Bookmarks significantly enhance the user experience by allowing quick access to different sections of the document.
3. **Efficiency**: In professional or academic settings, bookmarks help in referencing and reviewing long documents more efficiently.

## How to fix

1. **Identify Key Sections**: Determine the main sections or chapters of your PDF that would benefit from bookmarks.
2. **Create Bookmarks**: Use a PDF editing tool to create bookmarks at these key sections. Ensure that the bookmarks are clearly labeled to accurately reflect the content they link to.
3. **Organize Hierarchically**: If your document has sub-sections, consider creating a hierarchical structure in your bookmarks for better organization.

## Testing Methodology

Silktide scans the PDF to identify the presence of bookmarks in documents exceeding 21 pages.

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

### Limitations
- **Page Threshold**: Silktide uses a predetermined page count to trigger this check, which may not always align with the user's definition of a 'long' document.
- **Bookmark Relevance**: While Silktide can detect the presence of bookmarks, it does not assess their relevance or accuracy in representing the document's content.

## Further Reading

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

pdf-long-document-requires-bookmarks

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)

pdf-must-be-tagged

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

All pre-recorded audio and video should provide appropriate captions. This allows people who are deaf 
or hard-of-hearing to use the media. 

## Requirements
WCAG requires that captions:

* Represent all spoken dialogue
* Indicate who is speaking, when not visually obvious
* Include important non-speech sounds, like:
  * Laughter
  * Alarms
  * Music lyrics or tone (if meaningful)
  * Sound cues (e.g. _door creaks_)

## What this check looks for

This check identifies video and audio on the page, and checks whether that includes machine-readable captions.

This check will fail if:

* There is a video or audio element that is not muted, and it does not contain a caption track.
* There is a link to a known video platform (such as Vimeo) where captions are not clearly available.

## How this check works

### 1. Videos or audio using HTML5

The check scans for `<video>` and `<audio>` elements directly in the page’s HTML. For each one, it looks at:

* **Whether the media is muted**
  If the media is permanently muted using the muted attribute, the check ignores it. Muted media is assumed not to convey important information through audio.
* **Whether captions are provided**
  The check looks for a <track> element inside the media tag, which is where captions should be included. If no caption track is found, the media fails this check.

Only the first video file source is reported for each video, to avoid confusion from fallback formats.

### 2. Links to external video players

The check also looks for links to known video platforms such as Vimeo. If a link appears to go directly to a video 
and there’s no indication that captions are available, the check flags it.

## When captions aren’t needed

If the media is silent, decorative, or doesn’t include any meaningful audio content, then captions may not be 
necessary. However, in most cases where information is conveyed through audio, captions must be provided to 
meet accessibility requirements.

## Further reading

See [Understanding WCAG Success Criterion 1.2.2](https://www.w3.org/TR/UNDERSTANDING-WCAG20/media-equiv-captions.html).

prerecorded-captions-alternative

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

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

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

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

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

Ensure PDF documents are machine-readable for accessibility and usability.

## What this means

A machine-readable PDF is one that can be easily processed by software, such as text-to-speech programs, 
search engines, and other data extraction tools. This typically means that the text in the PDF is selectable 
and can be copied, as opposed to being embedded as an image.

## Why it matters

1. **Accessibility**: Machine-readable PDFs are essential for people using screen readers or other assistive technologies, as these tools require text they can interpret.
2. **Searchability**: Machine-readable documents can be indexed by search engines, making the content more discoverable.
3. **Content Usability**: Ensuring that your PDFs are machine-readable allows users to interact with the content more effectively, like copying text or searching within the document.

## How to fix

1. **Avoid Scanned Documents**: Whenever possible, create PDFs directly from text-based sources rather than scanning paper documents.
2. **Use OCR on Scanned PDFs**: If you have a scanned PDF, use Optical Character Recognition (OCR) software to convert the image-based text into selectable, searchable text.
3. **Check Font Embedding**: Ensure that all fonts used in the PDF are properly embedded so that the text remains accessible on different devices and platforms.

## Testing Methodology

Silktide examines whether there is selectable text in a PDF to determine if it is machine-readable.

## Further Reading

- [Creating Accessible PDFs](https://www.adobe.com/accessibility/pdf/pdf-accessibility-overview.html)
- [Guide to Machine-Readable PDFs](https://www.webaim.org/techniques/acrobat/)

pdf-not-machine-readable

An image with empty alternative text (e.g. `<img alt="">`) should not specify a 
`title` attribute, or if specified, the `title` should be empty.

For example, this is invalid:

```html
<img src="apple.png" alt="" title="This is an apple">
```

img-with-empty-alt-but-has-title

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

Priority	Recommendation	Progress
	Tag all PDFs WCAG 2.0 A 1.3.1	47%
	Allow users to quickly skip to content WCAG 2.0 A 2.4.1	95.6%
	Ensure dialogs have labels WCAG 2.0 A 1.3.1	33.3%
	Ensure links explain they open in a new tab WCAG 2.0 AAA 3.2.5	10.8%
	Ensure interactive components are far enough apart WCAG 2.2 AA 2.5.8	95.2%

Zundert

Accessibility

WCAG Levels

Recommendations

Do you own this website?