One in four adults in the United States has some type of disability. Many of these disabilities can impact how they interact with a computer and website in one way or another. During the urgency and “we need it yesterday” mentality that can surround urgent situations such as the state we are in now, how are you ensuring that your information is accessible for your entire audience?
Consider these five things as you’re adding and updating your websites with banners and other important information.
1. What is the contrast between the banner and the text within the banner?
Bright colors can be a problem as a background for black or white text. Make sure you have at least a 3:1 ratio of background color to the text color. The higher the contrast ratio the better for this case. Use a contrast checker like WebAIM’s.
2. Is your banner available before your “Skip to Main Content” button?
You may need to stop and check if your site has a “Skip to Main Content” button. You can typically find this by hitting tab after you load the page. If you find that you don’t have this, it’s a great time to add that in. This button exists to provide those users who use a screen reader or keyboard to navigate your site without having to go through the navigation every time the load a new page.
If the purpose of this link is to skip the repetitive content of the main navigation, we certainly do not want an alert banner to be included in that jump. Be sure that users can’t miss it by placing it before the “Skip to Main Content” button.
3. Consider having your banner announce itself.
It won’t matter to a user who cannot see the screen if your banner is bright red or yellow or at the top of the screen. There are coding methods that allow us to do what bright colors do for the eyes in auditory form. The WAI-ARIA alert role <role="alert"> is perfect for this. The alert role communicates important information to the browser, then a user receives the notification through their assistive technology, usually in the form of an audio screen reader. The alerts are used when the notification requires immediate attention for the user.
*This technique is invasive for users because it forces the user to hear the notification, therefore it should only be used when necessary. Assess your circumstances to determine if they merit this type of action.
Find more information on using the alert role here.
4. Posting emergency plans in a PDF?
It’s tempting to put together all-encompassing PDFs for emergency information. They are easy for a wide range of staff to produce and contribute to BUT when added to a website, they can be a giant roadblock for users with disabilities. There are a couple of routes you can take to ensure users can access this content.
You can avoid PDFs all together by putting that information directly into an HTML page. Providing the HTML structure of your site follows W3C best practices, and you apply proper styling to headers and break up long paragraphs of text, users will likely have a better chance of accessing the content over a PDF file that has not had any accessibility work applied to it. Review Page Structure Concepts from W3C’s Web Accessibility Initiative.
The second option is to set your PDF file up for accessibility. This is most easily done when the document is being created. Take a look at consideration #5 to address any graphs or tables that may live within your PDF. Check out more information on making your PDF accessible from Adobe.
5. Posting graphs of economic impact or other data?
Users like to see data visuals during an emergency. Tables, graphs and maps can be easier to digest for users over reading two or three paragraphs of text. This information is important to all users regardless of how they access it. These visuals should be accompanied by alternative text elements and possibly long descriptions that are linked directly before or after the visual. If an in-depth description can be included in the surrounding content, even better.
Some visuals only need an alternative text, while others afford users more in-depth information about the visual should they want it. Think of the difference between visually scanning through a math textbook versus extracting data from a particular graph for your benefit. As described in WebAIM’s in-depth article on alt text, the option of an in-depth review of the visual is what we’re after. We don’t want to force all users into it, but it’s best to have it available for those who are interested. The W3C’s WAI also has details on complex images.
The person who put together the graph or the content will be the best source of information on how to represent the important content in the context of why they included it in the first place.
*Note: the <longdesc> element is not universally supported with assistive technology thus is not recommended to support a complex visual. Read more about long descriptions in this article from WebAIM.
This list is not a comprehensive list of digital accessibility steps to take on a website. It is intended to provide a few key points of consideration that our team is thinking about. When it comes to digital accessibility, the only true way to know if the measures taken, are in fact usable and helpful to users with disabilities is to have those users test it out.