Skip to content

Commit c813028

Browse files
jazairijazairi
authored
Merge pull request #60 from MITLibraries/a11y-updates
Update a11y docs
2 parents 6d288ce + b69a630 commit c813028

File tree

1 file changed

+83
-51
lines changed

1 file changed

+83
-51
lines changed

‎basics/a11y.md‎

Lines changed: 83 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -1,68 +1,100 @@
1-
# Accessibility / a11y
1+
# Accessibility
22

33
## Background info
44

5-
[The A11y Project](https://a11yproject.com/about)
5+
Accessibility (shortened as a11y) is a primary consideration in our design and engineering processes. By foregrounding
6+
accessibility, we intend to make our web properties more equitable and usable for everyone.
7+
8+
The Libraries' Accessibility Team (LAT), established in 2023, has adopted [Inclusive Design](https://www.nngroup.com/articles/inclusive-design)
9+
as one of its guiding principles. Inclusive Design is similar to [Universal Design](https://universaldesign.ie/about-universal-design),
10+
in that both explore the idea of meeting as many people’s needs as possible. Inclusive Design focuses more on individual
11+
needs, and acknowledges that multiple design approaches may be required to meet this goal.
12+
13+
We consider Inclusive Design to be an inherently aspirational goal, as more can always be done. This is also what makes
14+
it a useful framing device for accessibility work. The human experience is incredibly diverse, and a single design is
15+
not likely to meet every person's needs. We can always strive to do better.
616

717
## Goals
818

919
- The site is usable by everyone.
10-
- Intentional access restrictions like MIT only are okay.
20+
- The site meets as many people's accessibility needs as possible.
1121
- Anyone that is authorized to use a site can actually use it.
22+
- Intentional access restrictions (like 'MIT users only') are okay.
23+
- The site is compliant with [WCAG 2.1 AA](https://www.w3.org/TR/2023/REC-WCAG21-20230921/) guidelines.
24+
25+
## Local software projects
26+
27+
Local projects should include an accessibility review. This should be added to the project timeline as early as possible
28+
in the scheduling process. The review plan should include a formal review by [Disability and Access Services](https://studentlife.mit.edu/das)
29+
towards the end of the project. The process and expectations for this should be discussed during the initial
30+
accessibility planning, but it has typically gone as follows:
31+
32+
- We develop an accessibility testing script (usually completed by someone in UXWS) and reach out to our contacts at DAS;
33+
- We meet with DAS to discuss what the app does and any specifics we'd like them to test;
34+
- We share the staging app with DAS, who complete their review and leave notes as issues a private GitHub repo;
35+
- We fix any open issues and confirm with DAS that they have been resolved.
36+
37+
While writing frontend code, keep the following tips in mind:
38+
39+
- Use valid HTML5 and our [style guide](/mitlib-style) to start with a good baseline for usable and accessible websites.
40+
- All Rails apps should include our [theme gem](https://github.com/MITLibraries/mitlibraries-theme/), which provides
41+
styles from the guide and various partials to improve accessibility.
42+
- Use semantic HTML elements and ARIA attributes where appropriate to help screen reader users navigate the page.
43+
- Ensure that every page has a logical tab structure.
44+
- Ensure that every page includes a skip link, so people using keyboard navigation can jump to the page's main content.
45+
(A customizable skip link partial is included in the theme gem.)
46+
- Run local checks throughout your development process (see [Accessibility testing](#accessibility-testing).
47+
- Consult with colleagues in EngX and UXWS if you find an issue that you either can't fix or your own, or aren't sure
48+
how to fix. Open discussions about accessibility issues often lead to the best-designed solutions.
1249

13-
## Local Coding Projects
14-
15-
- Local coding projects should schedule an accessibility plan review with UX
16-
early in the project.
17-
- Part of that plan will likely be to schedule an internal review with UX
18-
towards the end of the project.
19-
- Most projects should, coordinated through UX, schedule a formal review by [MIT
20-
Assistive Technology Information Center
21-
(ATIC)](http://studentlife.mit.edu/atic/) towards the end of the project. The
22-
process and expectations for this should be discussed during the initial
23-
accessibility plan review.
24-
- Use valid html 5 and our [style guide](/mitlib-style) to start out with a
25-
great baseline for accessible websites.
26-
- Run some local checks throughout your development process to fix any issues
27-
you can as they come up, but don't stress about trying to pass every test on
28-
your own.
29-
- Ask UX if something concerns you that you can't fix on your own so
30-
they can determine if they want to help now, or wait for the accessibility
31-
review at the end of the project.
32-
- Accessibility reviews from UX and ATIC will provide guidance on resolving any
33-
issues before or shortly after a project goes into production.
34-
35-
## Implementing Open Source or Vended Solutions
36-
37-
- Discuss with UX whether an accessibility review is appropriate and who will
38-
lead the review.
39-
40-
## Automated Checking
41-
42-
- All of our public GitHub repos are set to automatically check via
43-
[AccessLint](https://www.accesslint.com), which is great for what it is
44-
but is _not_ a comprehensive Accessibility Plan.
45-
46-
## Manual testing
47-
48-
- The [Web Accessibility Evaluation Tool (WAVE)](https://wave.webaim.org/) is
49-
useful for checking single web pages. It can be installed as a browser
50-
extension for either Chrome or Firefox.
51-
- The [Accessible Name & Description Inspector (ANDI)
52-
tool](https://www.ssa.gov/accessibility/andi/help/install.html) is a
53-
Javascript tool to evaluate a loaded webpage.
54-
- A screenreader like [VoiceOver](https://www.apple.com/voiceover/info/guide/_1121.html)
50+
### Accessibility testing
51+
52+
#### Automated testing
53+
54+
All of our public GitHub repos are set to automatically check via [AccessLint](https://www.accesslint.com). This is a
55+
useful tool, but is _not_ a comprehensive accessibility plan.
56+
57+
#### Manual testing
58+
59+
- For every pull request that touches a UI element, the author should run an accessibility checker tool to confirm that the
60+
change does not introduce an access barrier. In EngX, we use the following:
61+
- The [Web Accessibility Evaluation Tool (WAVE)](https://wave.webaim.org/) is
62+
useful for checking single web pages. It can be installed as a browser
63+
extension for either Chrome or Firefox.
64+
- The [Accessible Name & Description Inspector (ANDI)
65+
tool](https://www.ssa.gov/accessibility/andi/help/install.html) is a
66+
Javascript tool to evaluate a loaded webpage.
67+
- Some people navigate webpages by keyboard. To ensure accessibility for these users, it's a good idea to attempt to navigate
68+
the site periodically using your keyboard (e.g., when a new feature is added to the UI). This can help confirm that
69+
UI elements flow in a logical order.
70+
- A screen reader like [VoiceOver](https://www.apple.com/voiceover/info/guide/_1121.html)
5571
for the Mac or [NVDA](https://www.nvaccess.org/download/) for Windows can be
5672
useful for user testing to confirm that elements are reachable, or that
5773
interactions will play out as expected. Articles like ["Testing with Screen
5874
Readers" at WebAIM](https://webaim.org/articles/screenreader_testing/) are
5975
also useful.
76+
- While periodic screen reader testing can be helpful to identify issues, it has limited utility unless done by an
77+
expert user. (This will occur as part of the formal DAS review.)
78+
79+
## Implementing open source or vended solutions
80+
81+
As with locally developed software, any open source or vended software that includes a UI should be evaluated for
82+
accessibility. Any vendor claims related to accessibility should be confirmed, to the extent we are able to do so. UXWS
83+
should be consulted for accessibility reviews of vended products.
84+
85+
Ideally, accessibility should be discussed early in vendor negotations, and any potential issues should be addressed
86+
with the vendor.
6087

6188
## Resources
6289

63-
- [A11y Project Web Accessibility Checklist](https://a11yproject.com/checklist)
64-
- [HTML_CodeSniffer](https://squizlabs.github.io/HTML_CodeSniffer/)
65-
- [AccessLint](https://www.accesslint.com)
66-
- Chrome Dev Tools Accessibility Audit
67-
- [Google Developers Web Fundamentals: Accessibility](https://developers.google.com/web/fundamentals/accessibility/)
68-
- [Web Accessibility in Mind (WebAIM)](https://webaim.org/)
90+
- [Web Content Accessibility Guides (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/): a set of guidelines
91+
that is considered the benchmark for web accessibility.
92+
- [Section508.gov](https://www.section508.gov/): information related to Section 508 of the Rehabilitation Act, which is
93+
U.S. federal legislation related to IT accessibility.
94+
- [A11y Project Web Accessibility Checklist](https://a11yproject.com/checklist): a WCAG checklist that simplifies the
95+
guidelines for easier review.
96+
- [HTML_CodeSniffer](https://squizlabs.github.io/HTML_CodeSniffer/): evaluates HTML against WCAG or Section 508
97+
requirements.
98+
- [AccessLint](https://www.accesslint.com): a GitHub app that includes accessibility checks in CI. As previously noted,
99+
this should not be considered a comprehensive evaluation, bur rather one of many tools to evaluate accessibility.
100+
- [Web Accessibility in Mind (WebAIM)](https://webaim.org/): provides training and articles in accessibility.

0 commit comments

Comments
 (0)