-
Notifications
You must be signed in to change notification settings - Fork 22
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
Preventing accessibility issues before publishing #217
Comments
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 |
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.
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?
Why/when would certain rules need to be enabled disabled? |
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. 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". W3C's ACT rules are also useful as a pre-existing set of rules. |
@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) |
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.
The text was updated successfully, but these errors were encountered: