Accessibility: Frequently asked questions

In this article, we answer frequently asked questions about Accessibility in the following areas:

• Issues
• Potential Issues
• Page Sections
• Goal Setting
• DCI Score & History
• Resolved Issues
• Page Report: Code examples
• Integrations and extensions
• Siteimprove Accessibility (SIA) Rules

Issues

How is an Issue defined in Siteimprove Accessibility?

An issue is defined as a confirmed accessibility error that requires fixing. The code or content is invalid or incorrect and does not follow WCAG (Web Content Accessibility Guidelines) criteria or accessibility best practices.

Can an issue also be a potential issue?

Yes, a potential issue can turn into an issue and/or a resolved issue. In cases where automation is not able to make an evaluation, we will ask the users to provide feedback through a review flow, found on the Page Report. 

For example, Siteimprove can automatically detect the foreground and background colors. For these occurrences, Siteimprove will automatically classify them as issues if they have insufficient contrast. There will also be cases where automation is not able to detect the background color alone, in this case, you will be asked to use a color picker in the review flow to input the correct color.

Can I ignore an issue and remove it from my report, if I disagree with it?

If you identify an issue that you suspect is a false positive, you have the possibility of dismissing it.
You can read more about dismissing issue occurrences here.

How do I know who is responsible for fixing an issue? How can I assign ownership in NextGen?

It is possible to focus on issues that are relevant to particular skill sets using filters such as page section, difficulty, and responsibility. You can also create a dashboard with selected issues you’d like certain users to focus on, for instance, your technical partner or content editors.

See also: Configuring Siteimprove Dashboards and Dashboard reports

Can Siteimprove Accessibility test dynamic content for accessibility?

Dynamic content can be defined as content that appears on a page, or within an element after the user triggers a change to the page or the element. An example would be selecting a button that displays additional text on the page, a single-page form where additional input fields are revealed on the page only after the user has entered information into a previous field, or an interactive map or chart.

In the accessibility module, the crawler gets a static snapshot of this page, roughly speaking, after executing the onload scripts. We check that snapshot and nothing else.

Additionally, Accessibility only checks content that is rendered. Take the example of the interactive map, for buttons with text that is only displayed on hover, or after clicking, we will not check the extra content that appears.

For this reason, we recommend testing dynamic, interactive content through a manual assessment, with assistive technologies (screen reader software, keyboard, zoom magnification) to capture the user experience. If you have content that appears on mouse hover, for instance, a manual test is a good way of assessing this.

However, if you’re working with user-controlled content, you can use the Siteimprove Accessibility Checker browser extension to trigger the dynamic content then run the extension on the content and get a result.

For example, while testing a single page, open an expandable section or “accordion” to show the content inside. Run the browser extension to test with Siteimprove checks, and get the testing results immediately.

Potential Issues

Note: Have a look at this detailed Help center article explaining how to review potential issues.

How is a potential issue defined in Siteimprove?

A potential issue is a rule, that requires human review, by answering a series of pre-defined questions. After the user has completed the review, Siteimprove determines if the potential issue is in need of fixing. When a potential issue is determined as an issue, it will be moved under the ‘issues’ list.

Can I review potential issues in bulk?

The decisions you make on potential issues apply to all identical occurrences on your website. Nevertheless, you cannot bulk approve potential issues at once but will need to complete a review for each unique occurrence.

Are potential issues WCAG requirements?

Yes, WCAG requirements are A, AA, and AAA issues and potential issues. Issues and potential issues can be WCAG requirements and best practices.

When I complete the step-by-step review flow for a potential issue, where is my decision recorded? Can I edit or reverse my decision?

You can see the review decisions in the Page Report. You have the possibility to edit the review flow or see when and who made the action.

Should I start addressing Potential Issues or Issues first? What are the benefits of starting with potential issues?

In many cases, it is not an either-or decision. We expect customers to work on issues and potential issues at the same time. However, if you start conducting the reviews related to potential issues, you also begin building up a full list of confirmed issues, which can be a benefit before you start delegating the issues to your team.

Who should work through the review flow under Potential Issues? Is it technical or can my content author, do it?

The review flow is not technical. You do not need to be an accessibility expert. The review flow is intuitive and guides you through a series of questions that require simple interaction with the webpage such as verifying that there is audio on a video.

However, it is worth noting, that answers to questions in reviews are automatically reused where it makes sense and can affect multiple occurrences across the site.

If a potential issue is reviewed and moves under detected issues, will the number of points to be gained go up or stay the same?

Points would only be gained if no issues were detected in the review. Reviewing items and finding out they are true issues is not reducing your score.

How can I revert a review, that was completed wrong?

You can revert an issue to a potential issue in the page report, by pressing the icon with the three dots in the top right - “…” There, you can edit the answers to the review questions.

This can be done by someone who has User, Admin, or Account Owner permissions.

Page Sections

What are page sections?

Page Sections is a prioritization and ownership feature that allows different content and development teams to focus on issues that affect the parts of the page they are responsible for, and at the same time prioritize issues that span multiple pages.

For example, selecting the page section “Header” filters your Issues list to display only the issues that have been detected in the header of the page. This shortened list makes it easy to share the relevant issues with the team responsible for that page section.

How does Siteimprove determine what is the header and the footer on the page?

Page Sections allow us to distribute occurrences of issues by the ‘section’ of the page they occur in. Users can focus on a single or combination of Page Sections by selecting them from a Filter on the Issues Page.

An algorithm automatically generates four sections for each site: Header, Footer, Meta Data, and page content. The algorithm works by finding sections of repeated content across multiple pages and then analyzing which ‘section type’ that repeated content belongs to.

Can I edit and adjust the “header” and “footer” sections?

Yes, it is possible for Siteimprove to edit the sections. Technical Support will be able to update and make changes to the page sections.

How do I know which page sections the crawler is tracking?

This is shown visibly in the icons in the dropdown on the Overview page.

What is “metadata”?

Metadata is used to specify a character set, page description, author of the document, page language, title, and the viewport settings. This information can be found in the tag in your HTML code. The page sections filter enables you to filter to see issues in metadata only. 

What is in the “page content” section?

The Page content filter gathers together occurrences of issues that are located in the content part of the page. In this case, the Page content is all content except content in the header, footer, and metadata.

Goal Setting

What are “WAI-ARIA authoring practices” checks? What does it check for?

These checks help track the quality implementation of ARIA (Accessible Rich Internet Applications) – ensuring it is correctly implemented and used.

What are “Accessibility best practices” checks? What is included?

The best practice checks relate to content and code that has a significant impact on user experience but is not covered by WCAG. The category includes best practices that have been adopted by experts within the accessibility development and design community as an extension of the published web content accessibility guidelines. An example could be “Presentational image has accessible name” or detecting the use of heading tags on a page (H1, H2, H3) which enables screen reader users to navigate a page much quicker.

Why should I use “Accessibility Best Practice” checks if they do not cover WCAG compliance?

We understand that compliance with WCAG may be your most important goal. However, we have also incorporated best practice checks into the DCI score because these have shown, through feedback from real users, to have a significant impact on user experience. The checks are designed to guide designers, developers, and content contributors in implementing accessible code and content correctly and consistently.

When effort is made by your organization to make changes for accessibility, with our built-in best practice checks we are helping you to ensure these changes are effective. For this reason, we highly recommend adding best practices to your organization’s overall site target.

Examples of Accessibility best practices checks:

• “Presentational image has accessible name.”
• “Headings are correctly nested.”

What is WAI-ARIA?

WAI-ARIA stands for Web Accessibility Initiative – Accessible Rich Internet Applications, and it is a specification, that can be used to improve the accessibility and interoperability of web content and applications. WAI-ARIA is used specifically to provide an ontology of roles, states, and properties to define complex user interface elements so that they will be accessible for assistive technology users. For instance, ARIA can tell an assistive technology user if a drop-down menu is open or closed.

Who and how can we control the site target setting?

The site target can be changed by account owners. However, you have the option in Settings to give the edit option to other roles.

Can I control a “site target setting” just for my group or department?

No, the target covers the site. It is not possible to have different targets on a site. However, it is possible to have different site targets on an account.

What does Siteimprove recommend as the minimum goal?

Siteimprove recommends fixing all WCAG compliance and best practices rules, but at the same time acknowledges that a lot of our customers are focusing on WCAG 2.1 AA.

DCI Score & History

For a detailed overview of our score calculation, check out our help center article on DCI score calculation.

Can I remove Level AAA checks from the platform?

Yes, you can use the DCI site target to create a custom goal for your organization. The site target can filter selected issues, such as AAA issues and potential issues from the product.

How does the score breakdown in Accessibility work?

We calculate the issue score by taking the sum of the score from all issues in the category (A, AA, AAA, best practices, or ARIA) and divide the score by the sum of the maximum score you could achieve from all issues on the specific level. We then convert the score into a %.

This Accessibility score is calculated using a logarithmic scale. You will be awarded more points per occurrence fixed the closer you are to fixing all occurrences.

Resolved Issues

What are resolved issues, how are these defined?

These are occurrences that have passed the accessibility check.

What can I learn from perusing the resolved issues? How can they be used in the workflow?

These occurrences can be used to learn how to fix similar accessibility errors. Instead of only using the generic code examples from the Page Report, you have the option to use real-life examples relevant to your website.

Page Report: Code examples

Where do these code examples come from?

From the ACT (Accessibility Conformance Testing) Rules Format 1.0. Read more about Accessibility Conformance Testing rules here.

If I use the code example, does it make the code compliant?

The code examples are guidance showing diverse ways of meeting the WCAG success criteria. The code examples are accurate and relevant as recommendations for the code on the page.

However, there may be also more ways for passing the criteria, so you should consider the code examples as a “starter package.”

Will code examples be exported with the Issues list?

No, the code examples are currently available within the Page Report and our accessibility browser extension.

Integrations and extensions

Is there a browser extension for Accessibility?

Yes, you can download the Siteimprove Accessibility Checker Chrome extension from the Chrome Webshop or search for Siteimprove Accessibility Checker.

We have also released our new Accessibility browser extension for Firefox, Opera, and Edge browsers. The extensions can be found in the respective browser stores.

As previously, you can do single page checks and we will offer you an immediate overview of all the issues on the page. Like in the page report, the new extension will also provide you with specific recommendations on how to fix the issues and give you code examples to help you in the process.

Finally, it will give you information on which user types are affected by individual issues.

Is there a difference between accessibility checks in the Siteimprove platform and the Siteimprove accessibility checker browser extension?

The browser extension runs the same automated checks the platform runs. Semi-automated checks, however, are only run within the platform. This is because they require Siteimprove to store additional information that the free browser extension is unable to retain.

Differences between the platform and extensions can also occur when new rules and improvements are introduced, as different browsers can have their own processes for approving new versions of extensions. In some cases, this may take weeks. That's why it's possible for browser extensions to be running slightly older versions of the accessibility checks.

Siteimprove Accessibility (SIA) Rules

For more detailed information on our accessibility rules, check out our Guide to the New Accessibility Checks.

You can also find documentation on all our accessibility rules in one in the List of Siteimprove Accessibility (SIA) rules. 

What version of WCAG does Siteimprove report on?

We are reporting towards the latest version of WCAG 2.

Examples of rules added in the WCAG 2.1 are:

• 1.4.10 Reflow (A) - Page zoom is restricted (Issue)
• 2.5.3 Label in Name (A) - Visible label and accessible name do not match (Issue)
• 2.5.3 Label in Name (A) - Does the accessible name contain the visible label? (Potential Issue)
• 4.1.3 Status Messages (AA) - Status messages can be programmatically determined through role or properties by assistive technologies without receiving focus.
• Siteimprove rule: Field input error is not announced in full
• 1.4.12 Text Spacing (AA) - No loss of content or functionality occurs by setting all standards and by changing no other style property (Line height to at least 1.5 times the font size; Spacing following paragraphs to at least 2 times the font size; Letter spacing (tracking) to at least 0.12 times the font size; Word spacing to at least 0.16 times the font size)
• Siteimprove rule: Letter spacing is not wide enough 
• Siteimprove rule: Word spacing is not wide enough 
• Siteimprove rule: Line height is too narrow 

How does Accessibility incorporate WCAG 2 guidelines?

The Accessibility module includes the most up-to-date accessibility validation and reflects the rules that directly align with WCAG success criteria. Siteimprove is continually working to cover as many criteria as can be validated through automated testing, giving you better accessibility coverage. You can find the full WCAG overview on the Guidelines page.

You can be confident that at the core of our product, Siteimprove puts approved and confirmed rules, enhanced by best practices coming from our expertise in the domain. All this in order to ensure reliability and accuracy in your efforts to reach accessibility conformance.

More information on Accessibility

Visit this page for a full overview of the key features in the Accessibility module.