Why this matters
Team members who publish content online using a content management system (CMS) or social media platforms will have varying degrees of control over styles, formatting and code that is deployed to your digital properties.
Common publishing areas
- Content deployed through a content management system (CMS)
- Social media sites (Facebook, Instagram, TikTok, etc)
- Blogs / company news websites
- Press releases
Do your research
As the accessibility team, it’s important to understand publishing cycles, editorial processes, gatekeeping and QA practices.
Any content generated will be a mixture of authored content plus the code created by the CMS developers or social platform. Take the time to understand where authoring responsibility ends and platform responsibility begins.
- Some CMS authors may have a great deal of control over layout, design and code attributes.
- Others may be highly restricted by templates or lack of flexibility in tooling.
- Social media platforms vary in their support for accessible content and your team will have little to no control over presentation.
Authors do deliver code, whether they think they do or not
Some CMS and social 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 they are using the platform to deliver what is ultimately code. Culturally, they may even feel like they are simply cogs in a machine, delivering words and images into the void.
Team commitment KPIs
What requirements must the team agree to meet if your organization is going to be successful?
What obstacles must be acknowledged and removed for CMS and social media authors to create inclusive experiences?
Core responsibilities
While most of these are essential competencies for content strategy, they are all must-haves for accessibility.
Can explain why accessibility is a requirement
Team members can possess varying levels of technical understanding, but all should be alert to the basic reasons accessibility is a requirement.
Accessibility target policies
At a minimum, any team needs to understand accessibility targets exist, are defined by enterprise policy and enforced by leadership.
This bare minimum adoption achieves some level of compliance, even when it’s begrudging.
However, if the reasons for accessibility policies are taken to heart in service of the customer, products can dramatically improve.
Living your organization’s values
Accessibility isn’t just the right thing to do, it’s the smartest thing to do.
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.
Competitive advantage
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
While this mostly applies to CMS authors, some social media platforms allow for structured content like bullet points, emphasized and bold text surfaced to the screen reader.
Headings are more than bigger, bolder text. They contain meaning that forms an outline of the page.
- Start with a single
<h1>per page. There must be only one. <h1>is the meaningful title of the page.- Title major sections with
<h2> - Subsections of the
<h2>should be an<h3>. - It should be rare that
<h4>and beyond is required. - Only exceedingly long or extremely complex pages will need
<h5>or<h6>.
Headings example
<h1>Taco salad recipe</h1>
<h2>Ingredients</h2>
<h2>Steps</h2>
<h3>Vegetable preparation</h3>
<h3>Grilling the protein</h3>
<h3>Plating and serving</h3>
<h2>Nutrition information</h2>
<h2>Related receipes</h2>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.
Practical examples
- 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”.
Ensures video captions are present
Whenever a video with spoken audio content is published it must include captions.
Captions don’t just help people who are deaf or hard of hearing, they allow people in quiet situations (a library or a sleeping child) or noisy places (airport or a concert) to consume the video.
Uses emojis without creating barriers
Emojis are read by screen readers with inconsistently depending on the device and operating system. At times the Unicode name may be read or a system name may be used. Other times, the Emoji Modifier Sequence name may be used.
Red heart emoji
For example, a red heart emoji is read as “Red Heart” by:
- MacOS, iOS + Safari + Voiceover
- Windows + Chrome + JAWS
- Windows + Firefox + NVDA
It is read as just “Heart” in Android + Chrome + Talkback
This doesn’t present many problems in understanding its meaning, though it is read without any role.
Clapping hands
A clapping hands emoji is read as:
- “clapping hands sign” by Windows + Chrome + JAWS
- “hands clapping” by Android + Chrome + Talkback
- “clapping hands” by MacOS, iOS + Safari + Voiceover
Using this emoji inbetween every word to make a point would be a terrible experience with a screen reader.
A clapping hands emoji with medium skin tone is read as: “clapping hands modifier fitzpatrick type four” by Windows + Chrome + JAWS
In this case, JAWS (the most used screen reader in the US) reads the Emoji Modifier Sequence name, rather than the skin tone.
Save emojis for the end
It’s often best to use emojis for the end of text content, letting the text speak for itself and allow the emojis to be optionally consumed.
Don’t substitute emojis for words
Emoji names can vary by device, operating system and screen reader. That which is a clear visual substitution may sound very different when named by the screen reader.
Avoid emoticons
Emoticons (a series of punctuation and symbols used to illustrate an emotion or gesture) should be avoided if they contain critical meaning.
Example: These emoticons would be read as their literal punctuation.
- :) Smiley
- ¯_(ツ)_/¯ Shrugging
Uses aria-label only when necessary
Adding context with aria-label can help a customer using a screen reader understand the action of ambiguous links, buttons and inputs.
Practical examples
- A link to purchase coffee has the visible text “Shop today”. An appropriate aria-label might be “Shop today for coffee”
- A geolocation 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”
Assistive technology basics
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.
Testing for accessibility
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 basic 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.
Desktop
Keyboard
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.
Mobile
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.