Coming soon: Google and PwC share best practices on inclusive customer experience. Register now!

Our last post on the California Consumer Privacy Act of 2018 (CCPA) looked at the impact of the regulation in regard to web and mobile accessibility requirements. In this post we’ll look at how to translate the accessibility requirements of the CCPA into actionable guidance for notices and policies on websites and mobile apps.

Typical web pieces that fall under the CCPA requirements include:

  • Forms (such as requesting information on data collection or contacting an organization)
  • Documents (such as policies)
  • Alternative routes of requesting access (email, phone number)
  • Links and user interfaces (such as notices and controls of collection and opt out (or in) to specific requirements.)

In addition, the path to reach these notices, controls, and policy documents needs to be accessible to users with disabilities. The location of these specific elements may be tied to regulatory requirements of where these must appear on a page. Given that certain accessibility issues on a given page can impact access to the rest of the page, many of the pages that contain CCPA related content will likely need to follow the WCAG criteria to be reasonably accessible. For example, if moving or flashing content appear on a page which links the user to the privacy policy, the user may not able to reasonably access that policy.

As discussed in the previous post, following the WCAG 2.1 Level A and AA criteria for web content is the most straightforward path for meeting reasonable accessible web content covered by the requirements. WCAG Level AA conformance requires that Level A is met as a precondition to Level AA conformance criteria. These guidelines are an internationally recognized voluntary consensus standard that are intended to increase access to a wide audience of users with disabilities including those who use assistive technology. Assistive technology is software that is either built into the platform or third-party software that provides additional supports to users such as by providing text to speech, speech to text, or by other enhancements. This technology works by accessing the structure of how the web content was authored.

Web technology can, and often is, made very accessible to a wide range of users with disabilities. However, it’s not a given that web content will be inclusive. Depending on the libraries, design, frameworks, and other tools used to create web content, the accessibility or lack thereof can be profound.

Access Notice Controls

One of the most proleptic aspects of regulation are the cookie notices to opt-in/out (notices of collection). These are generally a plug-in product which often take the form of a notification banner on the home page or other landing pages and often have an additional settings page or modal dialog with cookie related settings. Common challenges include detecting the presence of this notice (which may appear at the bottom of the page), and methods for users who navigate web pages with the keyboard in a top to bottom fashion to effectively reach these notices. When notices or additional settings appear in a modal dialog there are typically issues with setting focus to the dialog, restricting focus to these dialogs and the accessibility of user interface controls, especially when inclusion has not been considered in their design. When inclusion has been considered, these notices and dialogs can be made accessible to users with disabilities both on the PC and mobile environments.


Some notices and policies may be in different formats such as PDF documents. The WCAG guidelines can be applied to PDF content as well. PDF documents contain a mechanism (often referred to as tagging) that allows for content to be structured in a way that can be access by users of assistive technology. How the PDF document was created and with what authoring tools will greatly impact the level of accessibility of the document. While PDF documents are commonly viewed right in the browser, users of assistive technology may view them in a viewer such as Adobe Reader.

Mobile Apps

Be sure to consider mobile apps, and any notices or documents located in these apps, because they will need to be accessible to people with disabilities. For non-web content user interfaces built into native apps that collect data or allow users to opt-out, etc., the WCAG criteria can generally be applied to these native mobile applications (with some slight differences). The same principles of ensuring the path to these notices and policies are accessible would apply. Commonly these are seen on disclosure menus or on pages accessed from a tab bar. The most common mobile platforms ship with built-in assistive technology and are generally very accessible when apps are authored for inclusion. If providing access to documents on mobile, these will be in HTML or PDF format as discussed above. Support for PDF accessibility on mobile devices varies by the platform and viewer used to access the PDF content, and thus web content is likely the safest choice for users with disabilities on mobile.

Other Formats

In some cases, notices may be provided in other non-online formats such as paper. In these cases, you will need to ensure there is a process or path for alternative format requests. For example, the request can be made via a phone number, email, or other method for an alternative to the paper notice. Alternative formats often include formats such as accessible digital format, large print, braille, or audio recording. Likely the most straight forward method would be to provide these notices online in accessible electronic format directly. Online electronic formats can be consumed by users with disabilities and converted into different formats by users. Consider that when you provide a communication method for the user to request information these methods must meet the effective communication needs of people with disabilities. For example, when a phone number is used to request deletion from a system it is important to ensure that there is a method available for users who are deaf, hard of hearing, or speech impaired to communicate their request.

In closing, it is important to carefully choose the plugins, frameworks, libraries, and document conversion tools used to create web content, notices, and policies related to the CCPA to ensure they are reasonably accessible to people with disabilities, including those who use assistive technology. Proper design and authoring of content is the best way to ensure inclusion and meet your obligations under the regulations.