Why this matters
Team members who publish content online using a content management system (CMS) will have varying degrees of control over styles, formatting and code that is deployed to your digital properties.
Do your research
It’s important to understand publishing cycles, editorial processes, gatekeeping and QA practices.
Some CMS authors may have a great deal of control over layout, design and code attributes. Others may be restricted by templates or lack of flexibility in tooling.
CMS authors do deliver code and some design
CMS authors and developers need to be in alignment, much like copywriters and developers.
Any CMS output will be a mixture of authored content and the code created by the CMS template developers. Take the time to understand where authoring responsibility ends and developer responsibility begins.
Some CMS authors may struggle to understand why they have to be concerned about accessibility.
They can feel removed from code and design processes. They may not see that they are using the content management system to deliver code. They feel like they are simply cogs in a machine.
Can explain why accessibility is a requirement
Team members possess varying levels of understanding.
The minimum level garners compliance. But when the reasons are taken to heart, your team’s performance can dramatically improve.
Accessibility isn’t just the right thing to do, it’s the smartest thing to do.
Living your organization’s values
Every organization has a set of values, often including core ethical tenets like treating people with respect and doing the right thing.
How does accessibility fit those values? How does ignoring accessibility breach them?
A tool for innovation
Accessible design and development builds better products for everyone. When teams put accessibility at the beginning of their processes, they create more valuable products for your enterprise.
26% of the US population has a disability that requires accommodation, making people with disabilities the largest minority in the United States. This adds up to billions of dollars in combined purchasing power.
Avoiding legal risk
Accessibility is the law. Designing and building accessibility into products also helps the enterprise avoid legal risk and liability due to a customer complaint.
Writes with logical headings
Headings are more than bigger, bolder text. They contain meaning that forms an outline of the page.
- Start with a single
- This is the meaningful title of the page.
- There should be only one.
- Title major sections with
- Subsections of the
<h2>should be an
- It should be rare that
<h4>and beyond is required.
- Only exceedingly long or extremely complex pages will need
Uses plain language
Not everyone understands content the same way. Emphasize being clear before being clever in your style guides. Plain language makes content easier for all customers to consume and understand.
- Avoid using idioms or implying jokes. This can be difficult for people who don’t speak english as a first language.
- Avoid technical jargon if a simpler explanation will do
Follows alt text conventions
Precise alt text conventions should be fine-tuned in your copywriting style guide.
Each image should have alt text for screen readers, unless including it would be annoyingly repetitive.
- Define alt text for images or icons when the image adds editorial meaning to the page.
- Good alt text allows anyone who can’t see the screen to describe it to someone else.
- Leave the alt attribute empty if an icon doesn’t add meaning or would be repetitive.
More of an art than a science
The copywriting style guide should determine a consistent voice for writing alt text and when to leave alt text undefined.
For instance, questions of when to call out gender, race, sexual orientation, etc., can be difficult to answer.
- Describe a banner image of a model using your product.
- Describe an image of your product in a specific color or configuration.
- Don’t describe a generic shoe icon next to a headline that says “Shoes”.
Uses aria-label for clear interactions
Adding context with aria-label can help a customer using a screen reader understand the action of ambiguous links, buttons and inputs.
- A link to purchase coffee has the visible text “Shop today”. An appropriate aria-label might be “Shop coffee today”
- A “Find my location” button features a map pin icon, but no visible text. An appropriate aria-label might be “Find my location”
- A site search input’s only visible label is a button with a magnifying glass. An appropriate aria-label for the search input might be, “Search this site” and the search button could use an aria-label of “Submit search”
Using assistive technology
While not everyone will perform full QA testing, team members should be able to perform basic actions with a keyboard and screenreader.
Can navigate a page using only the keyboard
Team members should be able to perform basic functions using only a keyboard like using the arrow keys to browse, tab key to focus and spacebar/enter key to activate.
Use screenreader shortcuts to hear headings, links and buttons
If someone is unfamiliar with headings beyond them being “bigger”, heading structure can be really difficult to comprehend in a practical way. Seeing a web page broken down into headings (h1, h2, h3) is the illustration that helps them understand the utility.
Assistive technology test suite
It may not be necessary for CMS authors to extensively test content in multiple platforms, but some degree of keyboard, screenreader and automated testing is a must.
Without access to testing tools, CMS authors will be left to throw code over the wall to QA, potentially creating a feedback loop that will waste time and money.
Prioritize your test suite by what devices and browser combinations your customers are using.
Setup of these tools can vary. For instance, if your team is already using Macs then they already have VoiceOver and can install NVDA using a virtual machine environment, without having to set up a separate physical PC.
Successful keyboard interaction is a prerequisite for testing with a screen reader.
PC + NVDA + Chrome
If you’re only going to test with one screen reader, it should be NVDA. It is free and it is very demanding of compliant code.
Mac + VoiceOver + Safari
If you’re testing with two screen readers, VoiceOver should be the second. VoiceOver is built into MacOS and pairs with Safari.
PC + JAWS + Chrome
Most of your customers with vision disabilities in the U.S. will be using JAWS because it’s subsidized by the federal government. JAWS is more forgiving of non-compliant code than NVDA or VoiceOver, so despite its market share, it is not always ideal as your sole testing platform.
iOS device + VoiceOver + Bluetooth keyboard
VoiceOver is built into iOS and pairs with Safari.
Android device + Talkback + Bluetooth keyboard
Talkback is a free screen reader for Android and pairs with Chrome.
Uniform automated testing tools
There are a multitude of free automated testing tools available. Simplify compliance by using one uniform tool used for development, QA testing and pipeline gating.