Best Practices for Overlays– Part 2

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.