Website Accessibility Tips
A lot of website accessibility guides are focused on requirements and tips for developers, who can directly change HTML and functionality to meet various criteria. However, the content itself makes or breaks a web experience for users with disabilities. Website accessibility is not only important for those living with disabilities but improves the digital experience for all users.
These 5 website accessibility tips are for CMS editors trying to build out an accessible website. Most of the bad habits listed are easy to correct once you know why they harm your overall site accessibility. Make it a goal to replace bad habits with good ones, and your users (and developers!) will thank you for it.
1. Fill in Every Heading Field
According to a 2017 WebAIM survey, 67.5% of screen reader users find information on a lengthy page by navigating through headings; far more than any other method. Headings are an extremely important factor in making sure that a page has a solid structure, and users can find the information they need.
Commonly, CMS blocks, components, and pages are built with a “heading” property or field (whether or not you can see it on the page). If you leave any of these heading fields blank, it creates a gap in the page hierarchy that makes it harder for screen reader users to understand what kind of information is contained. It can also lead to users skipping over your content entirely.
If you want to make your content accessible, but don’t want a heading to be shown, talk to your developers about your options. It’s possible to add a setting to the block that has the ability to add an “sr-only” or “visually-hidden” CSS class to the heading. 18f.gov has a great example of the styles necessary for implementing an sr-only or visually-hidden class. The corresponding styles render it invisible to users looking at the page while keeping it available in the page hierarchy for screen reader users. It is always recommended to keep headings visible, since some screen reader users are sighted or partially sighted and may be using a screen reader to follow along with the page. However, it’s more important to have a heading at all than have the heading be visible.
2. Check the Page Hierarchy Before Putting Headings in WYSIWYGs
Given that screen reader users rely on headings to navigate a page, it’s also important to make sure that the heading levels used are correct. Headings must increment by 1 level at a time in order to keep the page structure intact.
There is usually one H1 tag used on any given page; the page heading. From that point downwards, H2 headings are used to mark blocks or regions on the page. Regions inside those blocks should use H3 headings, and regions inside those should use H4’s…and so on.
WYSIWYG editors, or Rich Text Editors, are flexible editors that enable CMS editors to enter and format a wide variety of content. They are powerful, which helps editors create content the way they want it. But this power…comes with responsibility. Since these editors are present in many different contexts and inside many different regions, it’s important to make sure that you’re not inserting headings of the wrong level, in the wrong places.
If you’re a Chrome or Firefox user, there’s an extension you can download called HeadingsMap (Chrome, Firefox) that you can use to visualize the structure of a web page. It highlights in red any headings that don’t fit the hierarchy. Use this to make sure that you’re using the right heading element at the right time. Note that there can be false errors sometimes when a landmark region is labeled with aria-label instead of a heading.
If you’re concerned that the required heading level doesn’t match your design, your development team should have prepared (or can prepare) style presets that match the heading levels so that you can override the default heading appearance.
3. Add Alt Text to Images
In Episerver and Umbraco, the two main CMSes we use at Adage, you can apply alt text directly to an image asset, regardless of where it’s being used. Any and all images uploaded to the CMS should have alt text applied immediately. If an image is left without alt text, a screen reader will try to read out the name of the image, even if it’s “IMG_45w35452892hfafhsuhe.jpeg”.
Alt text should be able to convey the meaning of an image, and not just repeat a nearby caption or heading. If you have a region labeled “Puppies” and a photo of puppies below the heading, it’s much more useful to give that image alt text such as “Two puppies playing in grass” rather than “Puppies”, which is redundant.
Also, refrain from writing “An image of…” as part of your alt text. Screen readers give context for the alt text before announcing it, so it’s unnecessary.
Axess Labs has an excellent guide to writing effective alt text that can help you make sure you’re writing the best alt text for your images.
4. Don’t “Hack” Blocks or WYSIWYGs
As a CMS editor creating a page, it’s often tempting to use a provided page or block template in non-standard ways. You may want to add a blank Call to Action so you can use the background as a block of color or add a table into a WYSIWYG to add spacing between some elements. These hacks often create invalid code or elements that don’t relate properly to the content they’re serving.
Part of accessibility is making sure that the page content and markup isn’t misleading or confusing. A lot of CMS blocks will create landmark regions on the page, and if they aren’t being used properly, users can get lost and frustrated as they traverse the page.
If the problem you’re trying to solve is that you don’t have a block that looks the way you want it, discuss it with your development team. They could create a new block to suit your needs or may be able to add new options to an existing block that handle your needs more consistently. Or there might already be another standard way to achieve the effect you want by using another block or some other WYSIWYG formats.
5. Links and Calls to Action Should Be Clear and Explicit
“Learn More”, “Explore”, “More Info”, “See More” …all of these are examples of meaningless calls to action. Many users, especially screen reader users and users with cognitive disabilities, will be hesitant to take an action if the text doesn’t tell them what will happen when they use a particular link or button.
It helps sighted and screen reader users alike when calls to action are clear: “Learn About Memberships”, “Explore Education Resources”, “Parking Info”, “More Free Events”. A user should be able to predict exactly what they will find when they trigger that call to action.
You can learn more about what website accessibility means to your organizations, Web Content Accessibility Guidelines (WCAG) and some ADA work Adage recently completed for organizations in this presentation.
Download Site Accessibility Presentation
