Introduction

Best Practices for Overlays– Part 2

Best Practices for Overlays– Part 2

This week, I’m continuing with the second part of my Gaining Clarity on Overlays series. As I mentioned last week, this is part of my work to help the International Association of Accessibility Professionals (IAAP) develop a set of best practices for the overlays industry. These recommendations will be presented to IAAP after the mEnabling Conference in October—and will hopefully influence the overlay industry (including IAAP members and non-members), reduce the current level of conflict, and enable us all to get back to the business of improving accessibility

I received a lot of feedback to my last post. The Revised Set of Best Practices (below) includes all of the changes. I also described the comments in a separate Provision-By-Provision Analysis afterwards. Where single commenters contributed great ideas, I’ve acknowledged them (and hopefully paraphrased their ideas correctly). Please do not reach out to them regarding their comments because the fault is probably mine in unartfully translating their ideas.

A Revised Set of Best Practices

The following set of best practices is based on feedback from commenters.

1.    Technical Requirements

1.1 Follow W3C

If at some point W3C takes on work on technical recommendations for overlays, follow their lead. In the meantime, follow the best practices outlined below.

1.2 Dismissibility and Non-Interference

If an overlay has an overlay panel, make the panel easy to dismiss for assistive technology users (such as screen reader users) and for keyboard only users. Alternatively, don’t interfere with the screen reader and other assistive technology experiences.

1.3 Do Not Automatically Apply Settings

Do not automatically apply settings based on user behavior (e.g. starting a special “screen reader mode” simply because the user hits tab repeatedly) or based on detected user agent (e.g. starting a special “screen reader mode” simply because the user is detected as using a screen reader) or accessibility scanner (e.g. when an automated scanning tool is detected). Exception: overlays may automatically adjust color contrast based on detection of an automated accessibility scanner if they include a user control that adjusts color contrast.

1.4 Multiple Disabilities

If an overlay uses a control panel that tailors features to specific disabilities, be mindful of automatically turning off one set of features when a user selects a different disability. This should be a user choice because some users have multiple disabilities.

1.5 Be Lean

All overlays should be tested to ensure that they do not significantly slow computers.

1.6 Accessible

If an overlay uses an overlay panel, make sure that the controls in that panel are accessible and conform with WCAG 2.1 A/AA. Also, ensure that overlay panels follow standard navigation for controls—or disclose up front the manner in which users should navigate and operate those controls.

1.7 Document Fixes

If possible, provide a mechanism that identifies code level changes that are made by the overlay. This helps educate developers in avoiding future accessibility problems and also makes it easier to identify automated fixes that are applied incorrectly.

1.8 Meet Or Exceed Built-In OS Features

Many accessibility features provided by overlays already exist in the underlying operating system of many computers. Try to augment these features instead of simply replicating them.

2.    Non-Technical Requirements

2.1 Transparency (WCAG)

Be clear to customers which WCAG requirements are being automatically addressed, which ones require the overlay customers to fix, and which ones are not being fixed (or identified at all). Disclose the type of non-standard HTML content or controls that are covered by the overlay, AI, and/or manual remediation services (i.e., switches, tabs, etc.)

2.2 Transparency (Customers)

Don’t promise full compliance with the ADA or WCAG. Instead, give users honest advice about the limitations of your solutions and additional steps they should take for legal or technical compliance.

2.3 Transparency (End Users)

If an overlay provides a control panel or is otherwise easily identifiable by the end user, provide a simple non-technical explanation for end users—including end users who use assistive technology—about what is being fixed and what is not being fixed.

2.4 Respect User Privacy

Do not collect user data about requested accessibility settings. Or, if this information is collected, follow industry best practices for this data.

2.5 End-User Feedback

To help both the overlay provider and its customer improve the accessibility of its website, provide a dedicated mechanism to solicit accessibility feedback on any page when an overlay is deployed—including information about the specific problem and identifying information (e.g., email address) only if the end-user requests it.

Provision-by-Provision Analysis

1.    Technical Requirements

1.1 Follow WCAG

This best practice originally read as “The W3C is currently working on a set of technical requirements for overlays. Follow them. In the meantime, however, adhere to the following recommendations.” The first sentence (“The W3C is currently working on a set of technical requirements for overlays") is incorrect. The revised best practice shortens the language while preserving the W3C's technical leadership.

1.2 Dismissibility and Non-Interference

No changes were made from the first draft.

1.3 Do Not Automatically Apply Settings

This best practice originally read as, “Using an overlay should be a user choice and should not be invoked automatically. Also, overlays should not be applied based on user behavior (e.g., starting a “screen reader” mode simply because the user hits tab repeatedly).” Some overlays, however, are “transparent” with a goal of creating a single, optimized experience for all users. In this case, the settings are applied automatically. This behavior is now permitted under the revised language.

This best practice also merges in the content of the following best practice: Do not trigger updates to page content when an accessibility scanner is detected (Content owners need to verify accessibility of content without the effects of an overlay. Triggering an overlay may obfuscate their testing).

The exception was suggested by Lionel Wolberger. WCAG Technique G174 allows a web page with insufficient color contrast to meet Success Criteria 1.4.3 by providing a control that lets the user readjust the color contrast within a range that conforms to WCAG 1.4.3. Without this exception, a web page using an overlay to meet WCAG 1.4.3 would be identified as violating 1.4.3.

1.4 Multiple Disabilities

This is a new best practice based on a suggestion by Sheri Byrne-Haber. I originally wrote, “If an overlay uses a control panel that tailors features to specific disabilities, be mindful of automatically turning off one set of features when a user selects a different disability. This should be a user choice because some users have multiple disabilities.” Sheri’s rewrite is much better.

1.5 Be Lean

This suggestion comes from Adrian Roselli. Overlays often rely heavily on JavaScript, a just-in-time, weakly typed language. These features make JavaScript easy to read across different browsers and operating systems but burdensome for the user’s computer, which may already be burdened by assistive technology. In some cases, these features can make web pages operate very slowly with overlays.

The question here is what does it mean to “significantly slow” computers—and hopefully the next draft will answer that question. Some thoughts are “more than 10% of current load time”—but if anyone can add more precision, your comments would be appreciated.

1.6 Accessible

No changes were made from the first draft.

1.7 Document Fixes

No changes were made from the first draft.

1.8 Meet Or Exceed Built-In OS Features

This suggestion comes from Karl Groves. Many users (particularly older users) may be unaware of the accessibility features of their operating system. While overlays may make it easier to replicate these features, they should nonetheless try to augment them to full WCAG A/AA compliance.

2.    Non-Technical Requirements

2.1 Transparency (WCAG)

No changes were made from the first draft.

2.2 Transparency (Customers)

This best practice originally included the statement. “Don’t promise full compliance with the ADA or WCAG unless you mean it and can prove it.” The reality is that this can never be promised (see Updates to IAAP Code of Conduct, below). Also, advocates both for and against overlays suggested that this best practice should be elevated to being part of the Code of Conduct.

2.3 Transparency (End Users)

This best practice originally read as, “Provide a simple non-technical explanation for end users—including end users who use assistive technology—about what is being fixed and what is not being fixed.” I was going to delete this best practice at the suggestion of Dominic Varacalli-- either the solution should work or it doesn’t. In retrospect, I believe that this was in the context of overlays that do not have a control panel and that may be “transparent” to all users (i.e. an overlay that no user would know is on a page without a code inspection).

Removing this best practice for all overlays, created howls of protest—and in the context where an overlay is identifiable (e.g. through the presence of a panel or widget), this makes perfect sense. To make this distinction, I added the introductory clause “If an overlay provides a control panel or is otherwise easily identifiable by the end user.”

2.4 Respect User Privacy

This suggestion from Adrian Roselli is new—and hopefully it gets the idea and language correct. As Adrian explains, “every time a user activates a feature, they are self-identifying a need and possibly a disability.”

One obvious question here is what are “industry best practices” because there are no global privacy standards for user data. Also, global privacy standards vary between broad universal models (e.g. the EU’s General Data Protection Act) and sectoral models (e.g. in the United States, health data is subject to HIPAA and is subject to different rules than financial data, which is protected under the Fair Credit Reporting Act and the Gramm-Leach-Bliley Act).

2.5 End-User Feedback

Josef Pevsner suggested adding the word “dedicated.” This seems like a good idea—simply adding an email address is not an effective way of encouraging feedback on accessibility problems. The introductory clause (“To help both the overlay provider and its customer improve the accessibility of its website”) was added to make clear that this feedback mechanism was not meant to encourage accessibility complaints against the overlay provider or its customer.

Recommended Update to IAAP Code of Conduct

The following update to the IAAP Code of Conduct is based on feedback to the draft best practices.

Honesty to Customers

Given the current state of technology, it is impossible for any fully-automated accessibility solution (e.g. scanner, overlay, etc.) to ensure full compliance with the ADA or full conformance with WCAG. No member shall represent to customers that their fully-automated solutions can ensure legal compliance or find or remediate all accessibility problems.

This proposed update to the Code of Conduct was recommended by advocates on both sides of the overlay debate. On the one hand, this  update reduces overlay providers from being “singled out” in the accessibility industry by applying it to all fully-automated accessibility solutions, such as overlays, automated scanners, etc.

On the other hand, it provides some “teeth” through the IAAP grievance procedure to take corrective actions towards members that make hyperbolic claims around the benefits of using automated, one-size-fits-all solutions. For full disclosure, I was also asked by IAAP to develop this grievance procedure. This process will include identifying when individuals can file grievances against members and the process for handling those grievances. Details of that process will be coming later.

Got Feedback?

Wow, it’s clear that this draft of best practices (and addition to the Code of Conduct) is in the home stretch! But the devil really is in the details so I’m going to propose that the next round of edits take place over a two-hour Zoom session at 8a-10a Pacific Daylight Time (UTC -7) over the next few days (likely June 22, 23, or 24). If you would like to participate let me know by email to ken.nakata@convergeaccessibility.com—along with any blackout dates.

Participation in this session is subject to the following conditions:

  1. All attendees must come with the primary focus on improving accessibility for people with disabilities—and respect that all other attendees share this focus;
  2. All attendees must be respectful of the opinions of others and will limit their comments only to the provisions under discussion; and
  3. No attendees may record this event or use the contents of this event in any disparaging way—it is intended as a “safe space” for open, constructive discussion.

Special Thanks

Special thanks go out to Anil Lewis (NFB), Dominic Varacalli (AudioEye), Sheri Byrne-Haber (VMWare), Karl Groves (Level Access), Lawrence Shaw (AAATraq/SiteMorse), Josef Pevsner (National Organization on Disability), Lionel Wolberger (UserWay), Thomas Logan (Equal Entry), and Adrian Roselli (Self-Employed).

Want to See More Content Like This?

Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!

We're Here to Help When You're Ready

Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.

0 comments on “Best Practices for Overlays– Part 2

Leave a Reply

Your email address will not be published.