Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggested readability edits to Strengths and Weaknesses sections #425

Open
stringyland opened this issue Mar 18, 2021 · 3 comments
Open

Comments

@stringyland
Copy link
Collaborator

As with the introduction edits in issue #424 and the structure suggestion in #111, I've run the content through Hemingway and re-structured it a bit to get headings which I hope will give us a bit of an SEO boost.

The change I'm suggesting is to take the content from the 2 Strength/Weaknesses sections and the Fitness for Achieving Compliance section and rearrange them into two sections. The first would be Strengths of Overlays, which is general and only a short list of bullet points. The second is Weaknesses of Overlays which begins with a bulleted list, then subsections for the items we already have content for.

This should make it easier to scan the page, and to link to specific arguments. It will also make it easier to add new subsections for topics like privacy and performance as we get those expanded on.

New sections:

Strengths of accessibility overlays

If you want to know more about the benefits of a specific accessibility overlay, please consult the product website as each one is different. We have listed here some features common to most overlay products.

  • Most accessibility overlays are easy to install
  • Overlays may be useful to people who have recently acquired disabilities, and are not yet aware of the assistive technology available to them
  • Overlays with automated repair may be a useful temporary solution while you repair the site yourself
  • People without disabilities will feel good about doing business with an organisation which shows concern for people with disabilities

Weaknesses of accessibility overlays

Overlay products are unlikely to list their drawbacks on their marketing sites. However, accessibility overlays do have several problems which make it difficult to recommend that you use one.

  • Overlays add redundant widgets to your page
  • Overlays will not make you compliant with accessibility standards
  • Overlays with automated repair features cannot reliably fix many problems
  • Overlays invade privacy
  • Overlays cannot fix content that isn't in HTML, CSS or JavaScript (such as media files, PDF, Flash, Java or Silverlight) or in HTML5 canvas elements
  • Overlays add performance delays by loading scripts which must analyse and repair the code via the DOM
@stringyland
Copy link
Collaborator Author

Edited content from existing sections, to be put as sub-sections under the Weaknesses heading

Redundant overlay widgets

Some overlay products have widgets with controls to change the presentation of the page they're on. These controls might change the contrast or enlarge the text size. This might seem like a good idea, but their practical value is overstated. The people these features claim to help will already have the necessary tools on their computer, either as a built-in feature or as an extra app used to access not only the Web but all software.

For example, when someone needs a high contrast website, they need all websites to be high contrast, so they use a high contrast theme on their device. The widget's high contrast tool is redundant.

If you think your site's audience would benefit from widgets like this, but don't want the other problems that overlays can cause, please check the Alternatives To Overlays section below.

Automated repair is not reliable

Some overlay products aim to provide accessibility repairs to the page they're on. These repairs are applied after the page loads in the user's browser.

It's true that some accessibility problems can be fixed this way. But the usefulness of these repairs is limited by several important factors:

  • Automated application of text alternatives for images is not reliable
  • Automated repair of field labels, errors and focus control on forms is not reliable
  • Automated repair of keyboard access is not reliable
  • Modern component-based sites (made with ReactJS, Angular, or Vue) will change the state of all or some of the page based on user interactions. The overlay is unable to fix the updated content.
  • Repairs to the page can slow down page load times, or cause unexpected page updates for assistive technology users.

Some overlay products only perform automated repairs and are marketed as a temporary solution. These include Amaze by Deque Systems, Alchemy by Level Access, and Sentinel by Tenon. These products aren't in the same class of product as the overlays that provide widgets. Beyond the lack of a "widget", the biggest difference is that their manufacturers intend them to be an interim solution only.

Compliance with accessibility standards

One of the many claims made by overlay vendors is that using their product will make the site compliant with accessibility standards. These standards include WCAG 2.x, related and derivative standards, and laws that mandate compliance with those standards.

(blockquote) Conformance to a standard means that you meet or satisfy the ‘requirements’ of the standard. In WCAG 2.0 the ‘requirements’ are the Success Criteria. To conform to WCAG 2.0, you need to satisfy the Success Criteria, that is, there is no content which violates the Success Criteria.
Understanding WCAG 2.0: Understanding Conformance (end blockquote)

Conformance is defined as meeting all requirements of the standard. These products' documented inability to repair all possible issues means that they cannot bring a website into compliance. Products marketed with such claims should be viewed with significant scepticism.

@karlgroves
Copy link
Owner

@stringyland I apologize for letting this rot, but can you issues a PR with the changes you propose?

@stringyland
Copy link
Collaborator Author

@karlgroves Done! Feel free to suggest any changes or additional edits, happy to do whatever is needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants