May 2023

June 2023

July 2023

August 2023

September 2023

October 2023

November 2023

December 2023

January 2024

February 2024

March 2024

April 2024

May 2024

June 2024

July 2024

August 2024

September 2024

October 2024

November 2024

December 2024

Dickinson County, Michigan

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

Links must be defined in a specific way to be accessed by screen readers, which are used by 
blind and the partially-sighted.

To work with accessibility technologies, links must contain both machine-readable text, and 
a `href` attribute. If a link is not actually
pointing to a page or part of a page, it should be replaced with another semantic element, such
as a `button`, or the `<a>` tag should have a role of `button`. 

For example:

```html
<a href="/about">About us</a>
```

If the link contains _nothing but an image_, that image should specify alternative text, e.g.

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

Before HTML5, an anchor was often used to create a target to link to, e.g.

```html
<a name="example"></a>
```

This is not supported in HTML5, and the use of anchors for targets is discouraged. Use an `id`
attribute on a non-anchor tag instead, e.g.

```html
<div id="example"> ... </div>
```

Empty links (e.g. `<a></a>`) are often incorrectly used for buttons or controls in a
JavaScript application. In these cases, you should usually define the link as having a more appropriate
role, e.g. as a button. To do this, use the `role` attribute (e.g `<a role="button">`), or replace 
the `<a>` tag with a more appropriate tag, such as `<button>`.

For more details, see [Technique H91](https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H91)
and learn about [ARIA roles](https://www.sitepoint.com/how-to-use-aria-effectively-with-html5/).

bad-anchor

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

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

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

These adjacent links should be combined like so:

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

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

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

# Justification

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

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

This also simplifies your code. 

# Methodology

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

# Learn more

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

duplicate-adjacent-link

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

## Example

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

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

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

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

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

## How to fix

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

## More information

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

duplicate-id

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

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

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

* [WCAG 2.4.11](https://w3c.github.io/wcag/understanding/focus-appearance.html)

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

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

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

Users must be able to magnify the contents of a web page by up to 200%. In modern 
browsers this is almost always possible unless the page chooses to disable it.

Websites should avoid using the meta viewport tag to disable pinch-to-zoom. This behavior
is highly discouraged for accessibility and usability on mobile devices.

Generally the code causing this issue looks like this:

```html
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
```

Here the use of `user-scaleable=no` asks the browser not to allow user zoom. 

iOS no longer allows websites to disable pinch-to-zoom, and ignores this part of the
viewport tag. Therefore to replicate this issue you must use an Android device.

ensure-text-can-resize

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

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

There are two ways to comply with this requirement:

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

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

link-contrast

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

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

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

link-purpose-a

Avoid opening links in a new tab or window. Where you must do this, include an explanation
in the text of the link.

## Why this matters

Opening links in a new tab or window breaks the back button and can be disorientating for 
novice web users, and the visually impaired. Generally you should avoid opening links in a
new tab or window, but if you have to, you should include text explaining that this will happen.

## How to fix

An explanation must be clear in the accessible text for the link. For example:

```html
<a href="products.html" target="_blank">
    Products (opens in new window)
</a>
```

Or, for an image inside a link:

```html
<a href="products.html" target="_blank">
    <img src="products.jpg" alt="Products (opens in new window)">
</a>
```

Rather than updating all of your links manually to do this, you can add a simple CSS
selector, such as:

```css
a[target="_blank"]:after {
    content: " (opens in new window)";
}
```

Note that doing this with an icon, is not sufficient to pass this check. The text must be
readable by screen readers.

Alternatively you can override the link text for accessible technologies (like screenreaders),
so that the appearance of the link does not change. For example:

```html
<a href="products.html" target="_blank" aria-label="Products (opens in new window)">
    Products
</a>
```

Note that if you do this, the `aria-label` will replace the text content of the link completely,
so it must still make sense in isolation.

## Terminology

Although it is common to say "opens in new window", almost all browsers now use tabs, and
so this terminology is potentially confusing. You may prefer: "opens in new tab".

## Methodology

1. Silktide considers all links on a page with a `target` attribute of `_blank`.
2. For each link, Silktide considers the screen-readable text of the link, which includes:
   * The text content of the link
   * Any `alt` text inside any images inside the link
   * Any `aria-label` or `aria-labelled-by` text
   * The `content` of the pseudo-elements `:before` and `:after`
3. This text is analysed for the presence of common text, including "opens new tab"
    and "opens new window". If the text is not found, the link fails the test.

## Further reading

Generally best practice is to avoid opening links in a new tab or window.  

The W3C provides detailed guidance on 
[when opening a link in a new window may be appropriate](https://www.w3.org/TR/WCAG20-TECHS/G200.html).

link-text-explains-open-in-new-window

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

## Example

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

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

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

## Further reading

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

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

list-not-following-semantics

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

wcag-22.score

wcag-22-a.score

wcag-22-aa.score

wcag-22-aaa.score

website.pages

website.documents

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

Every page should precisely specify what language(s) it is written in. 

## Why this matters

Screen readers, which read out the text on a page, need to know the language to 
pronounce it correctly. Without the language, text may sound like gibberish. 

For example: imagine a computer pronouncing just one German word
"die" (pronounced "dee") using English pronunciation. Now extend that to every
word on the page.

Search engines may also use the language to classify pages, so this can have
an effect on SEO as well.

## How to fix

The `<html>` element should have a `lang` or `xml:lang` attribute which describes 
the language of the page.

You will usually want to use the `lang` attribute as follows:

```html
<html lang="en-US">
```

(Note this example won't work for XHTML, which is deprecated and highly discouraged).

Make sure you specify a [valid language code](http://www.rfc-editor.org/rfc/bcp/bcp47.txt).

## More information

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

Priority	Recommendation	Progress
	Ensure interactive components are far enough apart WCAG 2.2 AA 2.5.8	0%
	Ensure pinch-to-zoom is enabled WCAG 2.0 AA 1.4.4	20%
	Ensure text has sufficient contrast (AA) WCAG 2.0 AA 1.4.3	19.6%
	Ensure links are distinguished by more than just color WCAG 2.0 A 1.4.1	41.6%
	Ensure controls clearly indicate when they are selected WCAG 2.2 AA 2.4.11	97.9%

Dickinson County, Michigan

Accessibility

WCAG Levels

Recommendations

Do you own this website?