This documents will go over several of the different methods and standards used to make written documentation as accessible as possible.
When creating web content for your KB, it is important to keep in mind all audiences that may view that content. Making sure that your content is accessible to all web users ensures that anyone can view and understand your sites. Not all users interact with the web in the same way, so it is vital that your content is accessible in as many ways as possible. For more information about the importance of accessible content, take a look at Introduction to Web Accessibility.
HTML is the base structure of a page, and as such, must be correct for accessibility tools to work correct. Use an HTML Validator to check your code before publishing docs, as long as the page contains no confidential content. For more details on HTML structure you can read the WebAIM semantic structure guide.
Keep page organization as consistent as possible between articles, so that when a user goes between articles, the information is presented in a way that makes sense to them. If page layout/navigation differs between pages, it can end up in user frustration, and if a user is using something like a screen reader, only more so. Keep heading layout and link structuring as close as possible in between documents for easy navigation.
Good color contrast ensures that those with visual disabilities can use your pages. There are two standards for color contrast, AA (4.5:1) and AAA (7:1). you should target AA but AAA is nice to have. You can use a color picker browser extension and then check color combinations for compliance with the WebAIM contrast checker.
Is too descriptive, contains extraneous text (image of meaning can be conveyed in fewer words)
Bad alt text: computer coffee iced shop cold drink earbuds phone
Keyword stuffing instead of describing the image
Videos should not autoplay when embedded, so that they do not confuse and annoy users visiting your webpage. Subtitles or a transcript should also be included whenever possible so those with hearing disabilities can access your content.
String welcome = "Hello"; System.out.println(welcome);
TinyMCE, the newest KB editor, has a built-in accessibility checker that will inform you if there are any issues with your content. It can be found in the tools tab of the editor navigation bar, with an additional shortcut button in the editor toolbar.
When selected this will activate a pop-up with any issues, or an all-clear if there are none. This feature is also automatically triggered when the activate document button is selected.
See KB User's Guide - Documents Tab - TinyMCE Accessibility Checker for more information.
WAVE is a free web-based tool that can be used to scan an entire page and identify possible accessibility issues. Additionally, it provides useful information for understanding how your document structure (e.g. elements like headings) relates to accessibility.
WebAIM's Color Contrast Checker is helpful for verifying that text and background colors have sufficient contrast for users with visual impairments.
These A11Y "Nutrition Cards" for Accessible Components provide a handy reference if you are creating more advanced content that includes interactive elements such as accordions or buttons.
If you want to further check your pages for accessibility, you can use the WebAIM Quick reference or the more fully-featured WCAG 2 checklist and make sure that all the elements on the page meet all of the guidelines outlined in the list.
For more UW specific policy, you can view the official DoIT Make it accessible guides.
If you are aware of other free and useful resources for accessibility checking that you would like to see added to this list, please send your suggestions to firstname.lastname@example.org!
If you want a detailed overview of web content accessibility as a whole, this presentation from Kurt Murckstadt from the 2021 KB User Group Meeting goes into far more detail. See the document Creating Accessible KB Content to follow along with the presentation.