eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
During the past year, numerous high-profile companies, organizations and government agencies have witnessed a wave of digital accessibility lawsuits. In the government space, the number of federal website accessibility lawsuits nearly tripled between 2017 and 2018. Outside of government, Harvard University is one of the latest organizations facing legal action due to inaccessible digital content—specifically, failing to caption and providing inaccurate captions for a good portion of its public-facing online content.
The negative impact of digital inaccessibility can be huge. In addition to lawsuits, organizations can face lost revenues, penalties and noncompliance with government mandates. This includes the recently passed 21st-century IDEA Act, requiring all new and redesigned public-facing government websites to be accessible to people with disabilities.
Go here to read eWEEK’s listing of top project management and collaboration tools.
Global Accessibility Awareness Day (GAAD) fell on May 16 this year, a good reminder for development teams to consider a more proactive approach to accessibility.
This eWEEK Data Points article uses industry information from Preety Kumar, CEO and founder of Deque Systems, a digital accessibility company based in Herndon, Va.
Here are some steps to get started on this.
Data Point No. 1: Understand your specific accessibility needs, goals and requirements.
Different organizations face different accessibility requirements and considerations based on several factors, including the intended function of the digital property in question. Accessibility experts and digital accessibility lawyers recommend adhering to the Web Content Accessibility Guidelines (WCAG) 2.0 AA guidelines. These are international guidelines put in place by the World Wide Web Consortium (W3C) to measure and test for web accessibility. The scope of accessibility depends on the number of web applications or pages your organization has, but the way in which organizations or experts test for accessibility remains consistent.
If a website is transactional in nature (like ecommerce), special focus should be placed on ensuring that the transaction process and account management are functional and usable for people with disabilities and different types of assistive technology. For example, people with visual impairments often use screen readers when navigating websites. If an informative or descriptive image has no “alt text” (accessible image description) or uses something like a file name consisting of a string of obscure letters and numbers, the description read out by the screen reader will be of no help. However, if the text descriptor reads “click to buy pink cap-sleeved shirt,” it will be clear to that screen reader user.
Data Point No. 2: Integrate accessibility testing throughout the development process.
Failure to catch an accessibility defect after production is exponentially more expensive. Making a website or application accessible after production will also disrupt the software development cycle. Accessibility should shift as far left as the UX wireframes. Developers can take easy steps to address accessibility by using free automated accessibility tools, such as axe. This will catch 30%-50% of accessibility issues. Companies such as Microsoft suggest implementing the practice of being “axe clean” before code is shipped.
Data Point No. 3: Don’t forget to keep testing after deployment.
Although fixing accessibility in post-production is more difficult than accessibility testing throughout your development process, scanning and checking for accessibility defects after deployment is an important and necessary part of maintaining an accessible web page or application. Just as security is an ongoing functional requirement, accessibility doesn’t stop once a website or application is built. Developers are no strangers to components randomly breaking after deployment or making changes that have unexpected consequences. By scheduling regular audits of sites and applications after release, you ensure that new accessibility issues are found and fixed no matter when they happen in the product life cycle.
Data Point No. 4: Empower your developers to take ownership of accessibility.
A great way to foster your dev team’s enthusiasm for accessibility is to host empathy events, where your team can learn about and directly experience how people with disabilities use technology and how their disabilities and assistive tools impact that experience.
If your team values open-source projects and communities, there are more opportunities than ever to contribute to open-source accessibility software for the Web, Android, iOS and Windows platforms. It’s still early days for most of these projects, so there are lots of opportunities to make truly meaningful contributions.
Data Point No. 5: Start small and build on successes.
Accessibility can be daunting, especially given that many organizations initiate accessibility efforts under legal pressure. Keep in mind that accessibility is a journey, not a destination. Consider starting small—using free accessibility tools, enrolling your team in some accessibility training or arranging an empathy event—and scale up from there. The only way to ensure long-term accessibility success is to make it part of how your development process and overall organization operate. This can take a long time, but the good news is that each success is going to motivate your team and your organization to do more. Every step toward accessibility is a step toward making a tangible impact on someone’s independence and quality of life.
Data Point No. 6: Conclusion
Developers devote countless hours to making their organizations’ digital properties as informative, functional and engaging as possible. But if we overlook accessibility, we are excluding a U.S. customer segment estimated to be more than 40 million individuals. Embedding accessibility into all phases of the development process is a fundamental attribute of good software. Aside from being a public service mandate, it’s simply good business practice.
If you have a suggestion for an eWEEK Data Points article, email cpreimesberger@eweek.com.