robinknipe / accessibility-statement-generator Goto Github PK

Add an option to take an updated .md file and just do the generation to HTML (and other later actions, e.g. natural language linting).

Find a suitable [automated] accessibility testing tool and parse the test output so it can be included in the "Non-compliance with the accessibility regulations" section. This should allow for better testing automation and inclusion of accessibility testing in CI.
This feature should take test output (probably a JSON file) and produce a markdown snippet for inclusion in the standard template.
A template fragment for an issue should probably be created, for use here but also from other contexts.

If a project has declared it hasn't been tested yet it should be able to also declare it is exempt from PSBAR.

Try and write README help for users that aren't tech savvy.
Add help to configure things like the $EDITOR and $VISUAL env vars for nicer editors than vim!
Describe a workflow (perhaps a simple screencast as well) that shows off features from; first hitting the github project, to updating a previously created statement (both with the tool, and via json/md changes).

Allow npx to run asg from any npm project (without requiring the user to manually install anything).

Hi

I'm part of the Accessibility and Digital Inclusion team and I'm testing this out. I'm having an issue when trying to update this statement, either by the edit answers or regenerate statement options. I have attached my json file.

UnhandledPromiseRejectionWarning: SyntaxError: Invalid regular expression: /-v(?<version>\d+)\.\w+/: Invalid group at glob.map.p (/Users/chadgowler/Documents/GitHub/accessibility-statement-generator/plopfile.js:326:21)

Refugee Integration Loan-2020-10-09.json.zip

Rather than exhaustively listing all issues and non-compliances, perhaps just have a summary of the main concerns and then link to a separate exhaustive list.

Read markdown fragment file(s) specified as paths, and use the contents for the "Non-compliance with the accessibility regulations" section. This should allow markdown created in processes mentioned in #6 and #7 to be included in the generated statement.

Set the default editor to something else other than Vim

export VISUAL=not-vim
export EDITOR=not-vim

The current code has been hacked together in a hurry with little understanding of the underlying technologies. Hopefully now that the basic features work, improvements to the code base, and proper testing can be added!
Certainly any [non-configuration] code should be lifted out of the plopfiles and into proper source files.

Currently all exemptions must be entered manually, but there are likely to be many common examples that will apply to multiple projects, these should be captured in a checkbox prompt (with an option to add more manually). The following examples (and their appropriate descriptions) should be included:

• Live video
• PDFs and other documents
• Internal systems
• Archive with user generated content
• other (opens editor)

The GDS CSS classes should be used to help brand the statements.
A publicly hosted stylesheet can be statically linked from the head of the HTML version of the statement.
A question should probably be added to the plop flow to capture a preferred stylesheet (URL) supplied by the user.

The underlying library that does the transformation of markdown to HTML (unified) has support for processing more than these code languages, it can also process natural language. Using unified to "lint" the spelling, grammatical, and semantic content of the Accessibility Statements, should help:

• ensure proper spelling and grammar
• keep the wording simple and concise (a general expectation of all Gov content)
• spot existing problems in the output (e.g. double negatives, and other awkward wording)
• help ensure the quality of the resulting statements
• help safeguard against regression errors introduced by regeneration and automated processes (e.g. parsing accessibility test output)

Linting rules around sentence length etc. can be configured to meet Gov standards.

Currently the docs advise running plop as a shortcut to running the new statement generator directly; instead a proper ./asg shorthand should be available.

./node_modules/.bin/plop ==> ./asg new

Similar to #6
Assuming manual testing results that are captured in a spreadsheet (CSV file); take that tabular data and apply it to the same template used for automated test output.