October 2024

November 2024

December 2024

January 2025

February 2025

March 2025

April 2025

May 2025

June 2025

July 2025

Härnösand

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

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.

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. This is the stricter version of this check for 
Level AAA.

## Why this matters

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

## Examples

Most common examples include:

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

## How to fix

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

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

## Further reading

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

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

ensure-focus-is-not-obscured-enhanced

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

## Why this matters

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

## Examples

Most common examples include:

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

## How to fix

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

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

## Further reading

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

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

ensure-focus-is-not-obscured-minimum

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 fields, should ideally be large enough 
to be easily used by people with motor impairments. 

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

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

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

## Applying this check

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

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

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

## Methodology

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

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

## Troubleshooting

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

## Further reading

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

ensure-reasonable-target-size

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

WCAG 2.1 specifically requires this for:

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

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

extreme-zoom-scrolling

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.

## Further reading

See [Technique H32](https://www.w3.org/TR/WCAG20-TECHS/H32.html).

form-submit-required

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

The first heading in a PDF document should be a Heading 1. 

Failure to meet this indicates that either:

1. Headings are incorrectly structured (e.g. H2 before H1)
2. Or, the order of elements in the PDF is incorrect

## More information

See [PDF9: Providing headings by marking content with heading tags in PDF documents](https://www.w3.org/TR/WCAG20-TECHS/pdf.html#PDF9)
from the WCAG specification.

pdf-headings-h1-first

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

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

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

pdf-headings-order

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

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

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

pdf-long-document-requires-bookmarks

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

pdf-missing-default-language

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

pdf-missing-headings

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

pdf-must-be-tagged

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

pdf-no-title

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

pdf-not-machine-readable

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

Captions should provide the part of the content available via the audio track. Captions not only include 
dialogue, but identify who is speaking and include non-speech information conveyed through sound, 
including meaningful sound effects.

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

prerecorded-captions-alternative

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

WCAG 2.1 specifically requires this for:

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

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

two-dimensional-scrolling

wcag-22.score

wcag-22-a.score

wcag-22-aa.score

wcag-22-aaa.score

website.pages

website.documents

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

pdf-weak-title

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

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.

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

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

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

ensure-minimum-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="Apple">
</a>
```

img-in-link-missing-alt

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

All images, video, audio and other media should specify appropriate
[alternative text](https://help.silktide.com/articles/alternative-text/).

For example:

```html
<img src="apple.png" alt="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.

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

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

For example, this code should be avoided:

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

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

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

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

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

# Learn more

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

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

img-duplicate-alt

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.

Priority	Recommendation	Progress
	Ensure pages don't scroll in two dimensions on small screens WCAG 2.1 AA 1.4.10	0%
	Ensure controls clearly indicate when they are selected WCAG 2.2 AAA 2.4.13	11.2%
	Ensure focus is not fully obscured WCAG 2.2 AA 2.4.12	46%
	Ensure controls change appearance when they are selected WCAG 2.0 AA 2.4.7	90.8%
	Ensure pages don't require zooming and 2D scrolling on small screens WCAG 2.1 AA 1.4.10	96%

Härnösand

Accessibility

WCAG Levels

Recommendations

The best free accessibility checker