If you’re building a web accessibility initiative at your business, you can expect to meet some resistance. Most people will agree that accessibility is important, but they might not see it as a priority. That’s particularly true when the best practices conflict with the ways they’re used to working.
Developers, in particular, may be resistant to changing their workflows. Below, we’ll explain why web development teams might run into issues when adopting inclusive design techniques — and how the right mindset can help you avoid those frustrations.
Accessibility is often tacked on to the end of the project
Ask any dev, and they’ll tell you: When you’re writing code, implementing features, and constantly testing your work, you really need clear, unchanging requirements.
Unfortunately, digital accessibility is often incorrectly treated as a feature rather than as a principle. It’s something to check at the end of the project — and, if necessary, build into the finished product. That’s the wrong approach, and it leads to a ton of extra work.
For example, the Web Content Accessibility Guidelines (WCAG) requires labels for form fields, which isn’t difficult to implement on a single form. But if your website has hundreds of forms — and nobody labeled those forms during development — you’ve just created a job that will take hours of someone’s time.
Somewhat paradoxically, the more you prioritize accessibility, the less time you’ll actually spend on remediations.
Related: How Accessibility in the Web Development Process Saves Time
Devs sometimes believe that access is all about ARIA
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) is markup that defines the structure of web content for assistive technologies. It’s useful, but semantic HTML is more widely supported.
For devs, ARIA may seem like the most obvious solution to common accessibility problems. After all, it’s intended specifically for accessibility. It even has the word “accessibility" right in its name (twice!).
But by using ARIA, you’re making a commitment to test it. You’re also taking a risk; in some cases, misused ARIA attributes could make a website completely unusable for assistive tech users.
To be clear, ARIA can be crucial, particularly for complex websites. However, it’s just one tool — and other accessibility tools (like HTML and CSS) can be much more effective and much easier to work with.
Related: Why No ARIA Is Better Than Bad ARIA
Developers might focus too much on compliance
Compliance is a big deal. Businesses need to follow WCAG to limit their legal exposure under the Americans with Disabilities Act (ADA) and a number of other international non-discrimination laws.
But compliance isn’t the ultimate goal of inclusive design, and if you treat WCAG as a simple checklist, you’re going to run into issues.
That’s partly because WCAG isn’t purely objective. Testing many criteria will require human judgment and a solid understanding of the principles of accessibility.
It’s also because compliance, on its own, doesn’t always equal a good user experience. You can technically meet every WCAG success criterion while still creating a website, app, or product that’s frustrating to use.
For example, you might:
- Overuse ARIA attributes. As we’ve discussed, overusing ARIA can create new barriers for assistive technology users.
- Write complex code for simple elements. Sometimes, developers try to “fix" accessibility issues by writing extremely complex code, which inevitably leads to problems with long-term maintenance. In general, the simplest accessibility fix is the best solution.
- Create repetitive content. WCAG has guidelines for writing alternative text for images, captions for videos, and title tags for web pages. If you’re stuck in a compliance mindset, you might fulfill those criteria without adding any value for users.
WCAG is detailed and technical. Developers who approach it as a rigid set of rules may feel overwhelmed and lose sight of the core principles of accessibility — and the real, human users who will be affected by the changes.
Related: What’s the Difference Between Manual and Automated Accessibility Testing?
Digital accessibility means cleaner code and a better website
When developers view accessibility as an integral part of their work, the process of building inclusive websites becomes less of a chore and more of a rewarding challenge. By embracing tools like semantic HTML and incorporating user feedback from people with disabilities, developers can create solutions that enhance real user experiences while conforming with WCAG.
Starting with accessibility in mind from day one streamlines workflows, reduces the need for extensive remediation later on, and ultimately leads to more robust and inclusive digital products. To learn more, download our free eBook: Developing the Accessibility Mindset.
