Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update 2 pages with updated content #769

Merged
merged 6 commits into from
Aug 19, 2024
Merged

Update 2 pages with updated content #769

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
cd45e7e
Update statements.md
laflannery Aug 19, 2024
9c255a1
[pre-commit.ci] auto fixes from pre-commit.com hooks
pre-commit-ci[bot] Aug 19, 2024
b51b0cf
Update checklists.md
laflannery Aug 19, 2024
f77e64e
[pre-commit.ci] auto fixes from pre-commit.com hooks
pre-commit-ci[bot] Aug 19, 2024
f1a4d4a
fixing remark errors
laflannery Aug 19, 2024
b3fe796
Removing extra space
laflannery Aug 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 29 additions & 39 deletions _playbook/checklists.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
layout: playbook
title: Use checklists
description:
title: Using checklists in an accessibility strategy
description: How to incorporate checklists into a comprehensive accessibility strategy.
excerpt:
sidenav: docs
categories:
Expand All @@ -13,53 +13,43 @@
- Project manager
- UX designer
---
Checklists can be helpful for teams. They are usually insufficient to move an organization beyond a limited compliance mindset. There is no single checklist that covers all WCAG issues. As Intopia warned, [a checklist mentality can actually be harmful for inclusion](https://intopia.digital/articles/announcing-the-accessibility-not-checklist/). That said, if approached as part of a broader strategy, they can be very helpful. We recommend that teams might want to customize one to better meet their needs. Access Armada has some interesting suggestions on [more strategic approaches to checklists](https://www.accessarmada.com/blog/building-accessibility-checklists-that-are-actually-useful/). Ultimately though, regularly reviewing your checklists is important. They can be a powerful tool for teams to keep learning how to create more inclusive content.
The purpose of an accessibility checklist is to help identify accessibility issues in your product, website, or document. However, incorporating checklists into an accessibility strategy can often be tricky. One of the most common pitfalls when using or thinking about checklists is making sure you don't get stuck in a limited compliance mindset. There is no single checklist that covers all possible accessibility issues and as Intopia warned, [a checklist mentality can actually be harmful for inclusion](https://intopia.digital/articles/announcing-the-accessibility-not-checklist/). That said, if approached as part of a broader strategy, they can be very helpful when used thoughtfully. Access Armada has some interesting suggestions on [more strategic approaches to checklists](https://www.accessarmada.com/blog/building-accessibility-checklists-that-are-actually-useful/).

Check warning on line 16 in _playbook/checklists.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/checklists.md#L16 

Hard to read sentence (confidence: 5/7)         readability  retext-readability
Raw output 
    15:4-16:122  warning  Hard to read sentence (confidence: 5/7)         readability  retext-readability

Check warning on line 16 in _playbook/checklists.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/checklists.md#L16 

Hard to read sentence (confidence: 5/7)         readability  retext-readability
Raw output 
  16:349-16:587  warning  Hard to read sentence (confidence: 5/7)         readability  retext-readability

Microsoft's [Accessibility Insights](https://accessibilityinsights.io/) has both a FastPass and Assessment component. The Assessment component guides users through doing a manual review. Using this tool, organizations could:

* Run the FastPass's automated axe checks on every page.
* Check that the Tab stops follow a logical order when navigating with a keyboard.
* Look over the elements that are marked Needs reviews to see if there are elements where a manual review can identify whether it is an issue or not.
* Complete the rest of the assessment to ensure that the page meets WCAG requirements.

This is a time consuming process, but would give the reviewer a high level of confidence that the site has good accessibility.

One could also look to use a tool like WebAim's WAVE, ANDI, or Tota11y to scan a web page for errors. In which case a reviewer could do something like this:

* Scan the page with the WAVE Toolbar:
* Look for clear errors (red boxes with an X in them).
* See if the alt text effectively describes the images on the page.
* Ensure that there is sufficient color contrast.
* Do keyboard only testing (using just tab, shift-tab, arrow keys & escape) to navigate the page.
* Evaluate page for plain language using free tools like the [HemingwayApp](https://www.hemingwayapp.com/).
* Magnify the page up to 200% and look for usability and readability issues.
## What makes a good accessibility checklist
* The checklist should build on automated testing approaches.
* Provide role-based checklists so that different people in the organization are focused on different aspects of accessibility.

Check warning on line 20 in _playbook/checklists.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/checklists.md#L20 

Hard to read sentence (confidence: 5/7)         readability  retext-readability
Raw output 
    20:3-20:128  warning  Hard to read sentence (confidence: 5/7)         readability  retext-readability
* Checklists should be short, concise and easily understood by the majority of the team.

Check warning on line 21 in _playbook/checklists.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/checklists.md#L21 

`easily` may be insensitive, try not to use it  easy         retext-equality
Raw output 
    21:43-21:49  warning  `easily` may be insensitive, try not to use it  easy         retext-equality
* Allow for iteration of the checklists is needed - they may need to change depending on the element or learnings after going through the process a few times.

There are lots of checklists, rotating through a few of them will help give different people different things to think about accessibility:
## Example checklists
Sometimes, you don't need to reinvent the wheel. If there's already an existing checklist available, you can customize it to fit the needs of your team and product. Below are a few examples of existing accessibility checklists:

* [W3C's Web Accessibility Initiative (WAI)](https://www.w3.org/WAI/test-evaluate/preliminary/)
* Basic checklist, not designed to be fully robust but rather to give you a starting point
* [18F - USA Government](https://accessibility.18f.gov/checklist/)
* [UK's Government Digital Services (GDS)](https://gds.blog.gov.uk/2014/01/13/a-checklist-for-digital-inclusion-if-we-do-these-things-were-doing-digital-inclusion/)
* [WebAim](https://webaim.org/standards/wcag/checklist)
* [Elsevier's WCAG 2.1 Checklist](https://romeo.elsevier.com/accessibility_checklist/)
* Checklist geared toward US federal websites
* [A11yProject](https://www.a11yproject.com/checklist/)
* Robust checklist using WCAG criteria and broken update into element categories (e.g. Content, Images, etc.) with understandable action items

Check warning on line 32 in _playbook/checklists.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/checklists.md#L32 

Hard to read sentence (confidence: 5/7)         readability  retext-readability
Raw output 
    32:5-32:145  warning  Hard to read sentence (confidence: 5/7)         readability  retext-readability
* [Heydon Works](https://github.com/Heydon/inclusive-design-checklist)
* Checklist that includes not just items regarding accessibility but other inclusive design checks as well - device support, language, etc.

Check warning on line 34 in _playbook/checklists.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/checklists.md#L34 

`just` may be insensitive, try not to use it    just         retext-equality
Raw output 
    34:33-34:37  warning  `just` may be insensitive, try not to use it    just         retext-equality
* [VoxMedia](https://accessibility.voxmedia.com/)
* [PSU](https://accessibility.psu.edu/checklist/)
* [Yale](https://usability.yale.edu/web-accessibility/articles/wcag2-checklist)
* [University of Washington](https://www.washington.edu/accessibility/checklist/)
* [tmobile's A11yEngineer](https://github.com/tmobile/magentaA11y)
* [dev.to's Web Accessibility Cheat Sheet](https://dev.to/codegino/web-accessibility-cheat-sheet-3774#aria)
* [The Book on Accessibility](https://www.thebookonaccessibility.com/)
* Checklist broken down into categories for various practices area/role
* [Intopia's Accessibility Not-Checklist](https://not-checklist.intopia.digital/)
* This checklist can be customized directly on the site by specific WCAG standards and it can be filtered to display items by either topic or role

## Checklist
## Create your own checklist
While there are many checklists already out there and that can be customized to fit your needs, you don't necessarily need to use something preexisting. Using an existing automated scanning tool, you could create your own simple checklist process.

Check warning on line 41 in _playbook/checklists.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/checklists.md#L41 

`simple` may be insensitive, try not to use it  simple       retext-equality
Raw output 
  41:223-41:229  warning  `simple` may be insensitive, try not to use it  simple       retext-equality

* Have a checklist that builds on automated testing approaches.
* Provide role-based checklists so that different people in the organization are focused on different aspects of accessibility.
* Change your checklists so that new elements can be improved.
* Ensure checklists are short and concise enough that they are used.
For example, using a tool like [WebAim's WAVE](https://wave.webaim.org/), organizations could create a checklist to:

1. Scan the page with the WAVE scanning tool. View the details tab of the results console:
1. Review each error - designated by a red box with an X
2. Review each alert - designated by an orange triangle with an exclamation point
2. [Do manual testing](https://accessibility.civicactions.com/playbook/manual-testing) of the page
3. Evaluate the page for [plain language](https://accessibility.civicactions.com/guide/plain-language) using free tools like the [HemingwayApp](https://www.hemingwayapp.com/).

## Key questions
## Next steps
When you are ready to learn more, here are some further guides and resources that may help:
* [Manual testing](https://accessibility.civicactions.com/playbook/manual-testing)
* [Automated testing](https://accessibility.civicactions.com/playbook/automated-testing)

* Are you making good use of the time and attention of your staff?
* Are the checklists boring, or supporting your team?
51 changes: 31 additions & 20 deletions _playbook/statements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
layout: playbook
title: Update accessibility statements
description:
title: Accessibility statements
description: Information about accessibility statements, what they are, why a website should have one and what type of information should be included.
excerpt:
sidenav: docs
categories:
Expand All @@ -11,29 +11,40 @@
- Operations
---

Accessibility statements are concise declarations that highlight your commitment to inclusion, and ensure that there is a clear feedback loop for users who find barriers.
A complete, well rounded accessibility strategy should include an accessibility statement. But what exactly is an accessibility statement? How do you write one and what type of information should be included?

Accessibility statements should be clearly identified in the footer of every page of the website, and at a minimum they should include:
## What is an accessibility statement?

* why the department cares about people with disabilities;
* a reference to the standards followed;
* examples of accessible implementations;
* contact information, should there be a problem or question.
An accessibility statement is a public declaration that highlights the commitment of a company or organization to accessibility and inclusion.

Check warning on line 18 in _playbook/statements.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/statements.md#L18 

Hard to read sentence (confidence: 5/7)         readability  retext-readability
Raw output 
    18:1-18:143  warning  Hard to read sentence (confidence: 5/7)         readability  retext-readability

As leaders in the field, the [European Union](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32018D1523) and the UK now require accessibility statements on all of their government sites. In an effort to grow the practice, the UK published a [useful guide](https://www.gov.uk/guidance/make-your-website-or-app-accessible-and-publish-an-accessibility-statement) on writing accessibility statements that meet their requirements, and there are more approaches available in this [repository](https://github.com/accessibility/Accessibility-Statement). All [USA Federal agencies must also include an accessibility statement](https://digital.gov/resources/required-web-content-and-links/#accessibility-statement), but the regulations are not as well defined.
Accessibility statements are intended to provide site visitors with information about the accessibility of the website. This information can help people use and navigate the site by setting expectations around site standards and providing details about potential known barriers or technical compatibility.

Check warning on line 20 in _playbook/statements.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/statements.md#L20 

Hard to read sentence (confidence: 5/7)         readability  retext-readability
Raw output 
    20:1-20:120  warning  Hard to read sentence (confidence: 5/7)         readability  retext-readability

Check warning on line 20 in _playbook/statements.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/statements.md#L20 

Hard to read sentence (confidence: 5/7)         readability  retext-readability
Raw output 
  20:121-20:306  warning  Hard to read sentence (confidence: 5/7)         readability  retext-readability

As the final piece of the feedback loop, accessibility statements ultimately determine how well your organization is meeting its accessibility goals. They can help people who simply have their systems configured differently than the testing infrastructure or those who have more unique requirements, and they make it clear that there is always more to do. Ultimately, the goal is improving the site for all users and encouraging visitors to be a part of that process.
The [CivicActions accessibility statement](https://civicactions.com/accessibility-statement/) can be found in the footer of our main website.

## Checklist
## Why provide an accessibility statement?

* Appears in the footer of every page of the website.
* Highlights information that will help the user navigate the site more easily.
* Includes a feedback loop and encouragement for users to report barriers.
* Is there anything about PDFs or other digital content which is generally inaccessible?
In some cases there is a legal requirement, which is a very compelling reason to have one. For example, all US Federal agencies must maintain an accessibility statement with certain information as defined by the [Office of Management and Budget (OMB) memorandum](https://www.whitehouse.gov/omb/management/ofcio/m-24-08-strengthening-digital-accessibility-and-the-management-of-section-508-of-the-rehabilitation-act/) from December 2023.

Check warning on line 26 in _playbook/statements.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/statements.md#L26 

Hard to read sentence (confidence: 5/7)         readability  retext-readability
Raw output 
   26:92-26:437  warning  Hard to read sentence (confidence: 5/7)         readability  retext-readability

## Key questions
However, even if there isn't a legally mandated requirement, providing an accessibility statement on your website shows site visitors that you value accessibility as a social responsibility and that providing access to information is a priority for your organization.

Check warning on line 28 in _playbook/statements.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/statements.md#L28 

Hard to read sentence (confidence: 5/7)         readability  retext-readability
Raw output 
    28:1-28:269  warning  Hard to read sentence (confidence: 5/7)         readability  retext-readability

* What happens with messages (phone calls or emails) with errors that are submitted via the accessibility statement?
* Is it being reviewed regularly to see that it is still relevant for the site and it's users?
* Are extra efforts made to ensure that the accessibility page is accessible?
* Are there regulations about accessibility statements that apply to you?
## Writing an accessibility statement
At a minimum, the following information should be included in your statement:
* A commitment to accessibility
* The [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/) standard that the website or product adheres to (e.g. WCAG 2.1 AA)
* Any known limitations or existing issues that site visitors should be aware of to help to prevent frustration for the user
* Contact information for what to do if/when a user encounters a barrier or issue

The following additional information would also be good to include:
* Technical specifications, such as which browser/devices work well and which may have known compatibility issues
* Remediation plans for any known or existing accessibility issues
* Any links or references to applicable laws and policies
* Date the statement was last updated

Based on your particular website/product, there may be additional minimum requirements or some of the additional information mentioned above may be mandatory. For example, US Federal agencies must include (among other things) the date the statement was last updated and also a specific feedback mechanism for reporting issues to the appropriate 508 program office. When drafting your own accessibility statement, it is important to research specific requirements for your region and sector that may impact the information that should be provided.

Check warning on line 43 in _playbook/statements.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/statements.md#L43 

Hard to read sentence (confidence: 5/7)         readability  retext-readability
Raw output 
    43:1-43:159  warning  Hard to read sentence (confidence: 5/7)         readability  retext-readability

Also, remember that an accessibility statement is for site users, so it is important to write for that audience. Use [plain language](https://accessibility.civicactions.com/guide/plain-language) when writing your statement to allow users to easily understand the information you are telling them.

Check warning on line 45 in _playbook/statements.md

View workflow job for this annotation

GitHub Actions / remark-lint

[remark-lint] _playbook/statements.md#L45 

`easily` may be insensitive, try not to use it  easy         retext-equality
Raw output 
  45:242-45:248  warning  `easily` may be insensitive, try not to use it  easy         retext-equality

## Resources
* [W3C- Developing an Accessibility Statement](https://www.w3.org/WAI/planning/statements/)
* [Section508.gov - Developing an Accessibility Statement](https://www.section508.gov/manage/laws-and-policies/website-accessibility-statement/)
* [Model accessibility statement from GOV.UK](https://www.gov.uk/guidance/model-accessibility-statement)