Keeping Accessibility in Mind: Advice From a Web Accessibility Expert
Updated: June 3, 2019
Making your company’s IT both properly accessible to people with disabilities and compliant with accessibility laws means your organization must always keep accessibility in mind.
WebAIM (Web Accessibility in Mind) Associate Director, Jared Smith, recently lent some great advice in his presentation Implementing & Evaluating Web Application Accessibility.
To start off, here are some basic facts about web accessibility you may or may not have known:
- It supports good design and development practices.
- It supports and improves search engine optimization.
- It supports internationalization.
- It supports mobile-friendly content.
- 8.5-20% of the population has a disability that affects computer usage.
Regarding the last item in that list, Jared says this is actually a very conservative estimate:
He goes on to interpret this data as a business opportunity:
WCAG and Building ‘POUR Websites’
The Web Content Accessibility Guidelines (WCAG) 2.0 is the most influential, current, and comprehensive documentation of its kind, and is the standard internationally when it comes to web accessibility.
WCAG calls for websites that are POUR: Perceivable, Operable, Usable, and Robust. Essentially, this means organizations should integrate accessibility into the design of their website instead of considering it later on by looking for accessibility tools and programs that attempt to mimic a non-disabled user’s experience.
In Jared’s own words:
Best HTML Practice
Many people with visual disabilities including blindness, low vision, color deficiency, or color blindness use assistive technology to engage with websites and web applications. Common examples are screen readers and tools that enlarge text and images or change the color contrast.
These tools are very helpful, but if a website’s HTML, colors, or graphics were not implemented with these kinds of tools in mind, features of the website might be completely inaccessible to those with visual impairments.
To avoid that on your website or application:
- It’s typically best to use a single
<h1>header per page.
<h1>header should contain an accurate description of the page.
- Headings should define and follow a proper outline of the page’s content.
- Make sure to include alt-text on all images.
- Use HTML5 regions like
- Include labels in HTML that indicate buttons, forms, and other interactive elements.
Descriptive text needs to be included in HTML code so that visually impaired people using screen-readers and other devices can interpret where they are on the webpage. If interactive elements (like buttons and forms) are not labeled as such, then those users will be very confused about, or excluded from, what that webpage has to offer.
Also, labeling does not affect or change how the webpage normally renders. Therefore, it is a good idea to incorporate that descriptive text as part of your organization’s standard HTML-writing protocol.
A Quick Note on ARIA
In some cases, like with very complex webpages and applications, HTML is not sufficient for properly communicating content to a user. Sometimes, there is no HTML element to define or describe an object on a page. This is when ARIA tools (Accessible Rich Internet Applications) can be really handy.
ARIA, however, can actually make content inaccessible if you don’t use it properly. Jared says:
In our work with most of our clients, where we’re helping them with accessibility of web applications, we tend to spend more time telling them how to stop using ARIA than how to start using ARIA to enhance accessibility.
Very often ARIA is added when it’s not necessary, or it’s added incorrectly, and that can very, very easily destroy the accessibility of a web application. Even though it’s [meant] to enhance, it very easily can make things totally inaccessible to screen-reader users simply by adding one attribute to a particular element.
Evaluating Web Accessibility at your Organization
Only people, and not tools or software, can truly evaluate web accessibility.
The best way to evaluate user-experience is to have actual users experience your web content themselves and give critical feedback. Jared argues:
Jared recommends making a check list to make sure you cover every area.
User-testing can be applied and extremely useful in evaluating the level of accessibility in practically every area: keyboard testing, screen-reader compatibility, color and text visibility, caption readability, and any other sensory experiences your website or application offers as part of its content.
There are many tools that can help, as well. But it is important to recognize their limitations and remember they are just tools and not complete solutions. A great, free tool for helping with user-testing is WAVE, offered through WebAIM.org.
For more tips and advice on implementing and evaluating accessibility at your organization, watch Jared Smith’s presentation below:
Advanced Workflows for Captioning
Captions are time-synchronized text that represents the auditory information within a video. They are useful for viewers who can’t hear the audio, making it a great accommodation for those who are d/Deaf or hard of hearing. Accessibility isn’t the sole purpose of…
2020 Digital Accessibility Cases to Know About
In the webinar, 2020 Legal Update on Digital Accessibility Cases, Lainey Feingold breaks down the recent digital accessibility wins, cases to watch out for, and upcoming legislative changes to be aware of. Watch the 2020 Legal Update on Digital Accessibility Cases Recent…
4 Tips for Combatting Zoom Fatigue (When There’s SO Much Video)
Whether or not you’ve heard the term before, you likely know what Zoom fatigue feels like. The shift to a more remote workforce has resulted in someone joining a Zoom meeting 300 million times every day, meaning so many of us have…