February 2021

March 2021

April 2021

May 2021

June 2021

July 2021

August 2021

September 2021

October 2021

November 2021

December 2021

January 2022

February 2022

March 2022

April 2022

May 2022

June 2022

July 2022

August 2022

September 2022

October 2022

November 2022

December 2022

January 2023

February 2023

March 2023

April 2023

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

January 2025

February 2025

March 2025

April 2025

May 2025

June 2025

July 2025

August 2025

September 2025

October 2025

November 2025

EnLink Midstream

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

Most content should be written so people with a lower secondary level of education can understand it.
Where this is not possible, supplemental content or an alternative version should be provided.

This check highlights pages with a reading age of 16 years or higher. Only pages with at least 100 words
of content (excluding navigation, footers, etc) are considered.  

For more information, see [WCAG SC 3.1.5](https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-supplements.html).

ensure-reading-ability-is-not-advanced

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

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

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

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

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

link-purpose-a

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

To comply with WCAG 2.1, fields must identify what their purpose is _programmatically_. If done correctly,
this allows browsers to help users fill in forms with known information, such as their name and email address.

This is accomplished via the `autocomplete` attribute, which should be set to a 
[supported value](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete) wherever
appropriate, e.g. 

```html
<label for="name">
  First Name
</label>
<input id="name" type="text" autocomplete="given-name">
```

For fields where `autocomplete` is not appropriate, e.g. due to security, or the field not matching the
specification, the specific field should be ignored.

## Methodology

* All fields which could support `autocomplete` (e.g. text fields)
  are checked. Other fields - like dropdown menus - are ignored.
* The [accessible name](https://www.w3.org/TR/accname-1.2/) of each field is considered. In most cases this
  will be the `<label>` for the field.
* If the name matches a known pattern the field 
  must have an appropriate `autocomplete` value specified.
  For example, an `<input>` with type `text` with a label of 
  "First Name" would be expected to have an autocomplete value 
  of `given-name` or similar.

Note that using `autocomplete="on"` is not sufficient to pass this check, a
specific named autocomplete value must be used. See the
[supported values](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete).

## Troubleshooting

If a field is a false positive, check whether the field has an 
appropriate accessible name (i.e. a `<label>` or `aria-label`).

If the label is incorrect, Silktide may assume that the field 
requires `autocomplete` where it does not. You should fix the 
label to avoid this.

Otherwise, you can simply ignore the specific field.

## More information

* [How to use HTML 5.2 attributes](https://www.w3.org/WAI/WCAG21/Techniques/html/H98)

identify-input-purpose

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

Ensure the first heading in PDF documents is marked as Heading Level 1 (H1) for accessibility.

## What this means

In a well-structured PDF, the very first heading should be a Heading 1 (H1), which typically represents the main title or the most important heading in the document. This is similar to the primary heading on a webpage, setting the context for the content that follows.

## Why it matters

1. **Accessibility**: For screen reader users, an H1 heading is the primary entry point to understand what the document is about. It's crucial for navigating and comprehending the content.
2. **Document Structure**: The H1 heading sets the stage for the document's structure, much like a book's title. It helps in organizing the content logically.
3. **Search Engine Optimization**: For documents available online, having a clear H1 heading can aid in search engine recognition and ranking.

## How to fix

1. **Review Your Document**: Open your PDF and check the first heading. It should be marked as H1, clearly indicating the main topic or title of the document.
2. **Edit if Necessary**: If the first heading is not H1, use a PDF editing tool to change the heading level. Ensure that it is prominently styled and stands out as the main title.
3. **Maintain Hierarchy**: After setting the H1, ensure that subsequent headings follow in a logical hierarchical order (H2, H3, etc.).

## Testing Methodology

Silktide's identifies the first heading (if any) and verifies 
if it is correctly marked as H1.

### Limitations
- **Styling vs. Tagging**: Silktide detects headings based on tagging, not styling. A visually prominent heading might not be detected as H1 if not tagged correctly.
- **Document Variations**: In some documents, like research papers, the first heading might not be the main title. Silktide's check assumes standard document formatting.

## Further Reading

- [PDF9: Providing headings by marking content with heading tags in PDF documents](https://www.w3.org/TR/WCAG20-TECHS/pdf.html#PDF9)
- [PDF Accessibility - Headings](https://www.adobe.com/accessibility/pdf/pdf-accessibility-overview.html)
- [WCAG Guidelines on Headings](https://www.w3.org/TR/WCAG21/#headings-and-labels)

pdf-headings-h1-first

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 PDFs must define a descriptive title. 
See [PDF 18](https://www.w3.org/TR/WCAG20-TECHS/PDF18.html) for details.

pdf-weak-title

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

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.

Priority	Recommendation	Progress
	Ensure text has sufficient contrast (AA) WCAG 2.0 AA 1.4.3	0%
	Ensure lists are marked up correctly WCAG 2.0 A 4.1.1	0%
	Ensure PDFs have a title WCAG 2.0 A 2.4.2	23.5%
	Ensure content is not too difficult to understand WCAG 2.0 AAA 3.1.5	33.3%
	Tag all PDFs WCAG 2.0 A 1.3.1	64.7%

EnLink Midstream

Accessibility

WCAG Levels

Recommendations

The best free accessibility checker