Preventing accessibility issues before publishing

[edwardkerry]

There are a number of common accessibility issues which are frequently included in our documents.
They are currently being published without any automatic detection, and publishers are unaware that they are inadvertently publishing inaccessible documents.

We are hoping to add some new functionality to Govspeak to allow certain accessibility issues to be detected and the user alerted at the earliest possible opportunity.

How

Our proposed approach is to add an AccessibilityValidator class similar to the existing HtmlValidator. The AccessibilityValidator will have access to a range of additional methods to parse submitted GovSpeak and detect accessibility issues.

The AccessibilityValidator will be able to accept arguments to allow certain rules to be enabled or disabled.

Consuming applications that wish to use the AccessibilityValidator will create their own interface similar to Whitehall's SafeHtmlValidator, and any models can then set their required accessibility rules to validate against.

validates_with AccessibilityValidator, attribute: :body, accessibility_rules: [:foo, :bar]

Should an attribute fail any of the rules, a standard Rails validation error will then be displayed upon attempting to save, allowing the user to correct the issue and prevent any further accessibility issues being published.

Request

Please ask any questions or point out any concerns or issues about this approach.

[chao-xian]

When you say adding a validator, are we maintaining one or using something that that has a set of rules that can validate for us?

[edwardkerry]

When you say adding a validator, are we maintaining one or using something that that has a set of rules that can validate for us?

@chao-xian we will be building and maintaining our own validator and rules

[kevindew]

Thanks for raising this Ed ⭐,

Do you have a list of the initial accessibility issues this would handle? it'd be good to have an idea of the scope of what is being proposed.

I am a bit concerned that adding a validator will create a fresh world of confusion because of the sheer amount of things that could be validated in govspeak (correct link formatting, footnote formatting etc) and only picking a few accessibility concerns. With the existing ingrained convention being, you do your govspeak wrong it doesn't render. I'm also a bit concerned it could be hard to identify problems if you are a long segment of govspeak.

Do you know if you actually need/want to scope to be Accessibility only? I'd imagine if we do add a validator you might want it for govspeak as a whole rather than one scoped to accessibility.

validates_with AccessibilityValidator, attribute: :body, accessibility_rules: [:foo, :bar]

This seems to imply a Rails validator, would this be a coupling of this project to ActiveModel/Rails (it currently has a weak dependency through govuk_publishing_components)

Would you have multiple errors potentially e.g. foo and bar errors? or would they be a single concern? And what would happen if you had the same foo error multiple times?

The AccessibilityValidator will be able to accept arguments to allow certain rules to be enabled or disabled.

Why/when would certain rules need to be enabled disabled?

[selfthinker]

A couple of things...

govuk-accessibility-reports are a set of scripts to be run across all of www.gov.uk to check for some kinds of accessibility issues with content. Caveat: There are not many useful checks yet, and they cannot currently be run.
I always thought it would be more useful to run such checks against a single page when someone hits submit. You might not need to stop someone from publishing but could at least show some warnings. (Or both depending on type of issue.)

A few months ago I've looked into which WCAG criteria could fail when only using Govspeak. That's the maximum amount of WCAG fails you would need to check for. Although it would be useful to check other accessibility issues as well, not just those which would fail WCAG. And some of the WCAG fails cannot reasonably be checked either. For example, you can check that a linked image has alt text but you cannot check that the alt text makes sense. And while you cannot check for the quality of link texts you could at least check some common bad ones like "click here" and "more".
Although we would never be able to ensure 100% WCAG compliance that way (because some things always need to be checked manually), it would be good if we could at least prevent the most common detectable accessibility issues.

W3C's ACT rules are also useful as a pre-existing set of rules.

[KludgeKML]

@selfthinker one possibility is using a markdown linter (eg https://github.com/markdownlint/markdownlint) with configurable rules. That would allow us to pick out some of the issues in your linked document. (Obviously it couldn't check the softer ones like alt text making sense)