Why Accessible Websites and Mobile Applications Matter

The Internet is an essential part of life in the 21st century. A 2015 Nielsen study found that people spend an average of 2.5 hours a day using smartphones and PCs to access the Internet.

Look at any website or app and think of how different the experience would be if you couldn’t see it or hear it like everyone else.  The American with Disabilities Act (“ADA”) was enacted in 1990 to ensure Americans with disabilities had equal access to places and things such as government facilities and places of public accommodation.  Soon after the ADA was enacted, a new communications medium arose – the World Wide Web, marking the start of the Second Age of the Internet.  The question soon arose as to what extent websites were “places of public accommodation” requiring reasonable accommodations to allow use by disabled Americans under the ADA.  The Department of Justice has repeatedly delayed its rulemaking on website accessibility guidelines, most recently postponing it to at least 2017.  This may be due to the explosion of apps on the Internet and the corresponding decrease in website usage – a recognition that the landscape of what would be regulated is changing too rapidly at this point.

However, don’t think you’re safe to just wait for the DOJ’s guidance. Even without rules, the DOJ has gone on record stating that the ADA applies to web services. The DOJ has instituted a number of lawsuits against companies which they believe are not meeting accessibility standards, including their websites and apps.  For example, in 2015 the DOJ settled with Carnival Cruise Lines requiring not only improvements in accessibility of its ships, but of its website and mobile application.  Many US companies are unaware that under Section 508 of the United States Workforce Rehabilitation Act of 1973, websites and apps developed by companies receiving federal funds or under contract with a federal agency must meet certain accessibility standards.  Private and government litigants continue to bring actions against companies under federal and state law for inaccessible websites – over 45 in 2015 alone, according to BNA.  There have reportedly been many more demand letters sent to companies concerning digital properties allegedly inaccessible by persons with disabilities.

Despite the uncertain landscape, there is a path forward to minimize the risk that your company’s digital properties will come under scrutiny or attack. All companies, and especially those currently or prospectively doing business with the government, should make accessibility part of the calculus when designing, building, and refreshing websites and mobile applications. Here are some important considerations for companies.

(1) Ensure your web and app developers are familiar with WCAG 2.0 standards and Section 508 requirements. Although the DOJ has not yet released its own rules, they continue to use Version 2.0 of the Web Content Accessibility Guidelines (WCAG 2.0) as a de facto standard.  WCAG 2.0 was released in 2008 and became an ISO standard in 2012. There are 4 core principles for web content under the guidelines:  content must be Perceivable (e.g., alternatives for non-text content, alternative content presentation, separate foreground and background content, etc.); Operable (e.g., make all functionality keyboard-accessible, allow sufficient time to read content, ensure navigation and search are easily usable, etc.); Understandable (e.g., clear text content, predictable operation of web pages, etc.); and Robust (e.g., use standardized and proper tagging; ensure content can be interpreted reliably by varied user agents such as assistive technologies).  While there are 3 levels of conformance with WCAG – A, AA, and AAA – AA is the most common and the one referenced in most litigation and DOJ actions.  Additionally, Section 508 imposes specific obligations on software applications and operating systems and intranet and Internet websites.

It’s very likely a future version of WCAG will form a foundation of the DOJ’s guidance; the DOJ has referred to the WCAG as a recognized international industry web accessibility standard. If the DOJ’s advice aligns with this standard, it will likely mean only minor accessibility adjustments will be required by companies that are already WCAG compliant. If you have international users of your digital properties and/or an international presence, consider whether international standards such as Canada’s Standard on Web Accessibility, the UK’s Disability Discrimination Act, and France’s AccessiWeb impose any obligations above and beyond WCAG 2.0 AA.

(2) Ensure your app developers are also familiar with and OS assistive capabilities such as Google Talkback and VoiceOver for iOS.  Google and iOS both have assistive software.  Apple offers VoiceOver, a gesture-based screen reader integrated with iOS.  Google Talkback similarly enhances Android with spoken, audible and vibration feedback to better enable use of Android devices by visually impaired persons.  Your app developers should understand these and other assistive technologies available for app operating systems so they can utilize them to the fullest extent possible.

(3) Perform an accessibility audit of your digital properties. An accessibility audit will help you understand what accessibility improvements are needed to ensure WCAG 2.0 AA and Section 508 compliance, as well as the cost and resources that will be required for your company to achieve compliance.  Being able to demonstrate the costs of compliance vs. some of the settlements forced by litigants and the DOJ can help add a quantifiable metric to the risk analysis. An internal audit can be helpful to ensure your internal team understands the accessibility requirements, but also consider using third party tools and partners such as SiteImprove, IBM’s Rational Policy Tester Accessibility Edition, ACCVerify, or ComplianceSherriff.

(4) Make “accessibility by design” part of your creative development process. Many of the visual design elements we take for granted, such as layouts, have a very different meaning (if any) to a visually disabled person. Audiovisual content is very different to a hearing-impaired individual – if can be very difficult for a captioned video to deliver the nuances of inflection that often go into a vocal performance.  Consider the user experience of someone hearing your copy (not just reading it), or reading your video or narration (not just hearing it).  Consider having your marketing and design teams use screen readers and watch captioned videos for a better understanding of that experience with their content. Include audio captions in videos or narrated presentations to assist hearing-impaired individuals. Look at what features and functionality are available to assist you with enabling accessible creative content.

(5) Make it part of your coding and testing DNA, too. Ensure your web design techniques promote accessibility. Make the WCAG 2.0 AA guidelines, Section 508 requirements, and OS assistive capability support part of your development requirements for any new coding project or project refresh.  When contracting with web and app developers and with web and commerce platform vendors, ask them for examples of projects they’ve done which were assistive technology and guideline compliant, and require them to follow accessibility guidelines. Use web design tools that support and enable accessibility.  When you develop customer profiles for testing, consider adding profiles for visually-impaired and hearing-impaired users.

Website and app accessibility compliance can seem daunting, but it doesn’t have to be. Knowing accessibility requirements and guidelines, and your company’s current implementation of them in their digital properties, is an important first step.  Making a plan to build accessibility into your company’s design and development DNA, and implementing accessibility support and features in your digital properties, can help keep you ahead of both accessibility litigation and future government regulations.

Leave a Reply

Your email address will not be published. Required fields are marked *