Data Science Campus faculty accessibility process 2022
This accessibility process was developed by the Office for National Statistics (ONS) Data Science Campus. It applies to anyone reviewing, updating or creating content for a training course. This process can also be used for documentation and presentations.
For more information about our implementation of this accessibility process, read our blog post.
Preparing your material
Before you start, generate a folder with accessibility reports for all existing material, listing the issues you have identified. This ensures a detailed record of any necessary improvements is available, which can be measured and reported once the work is complete.
Stage 1 – check the existing documentation on accessibility
Step 1
Use a tool like wave webaim to determine if the course or material has already had accessibility checks.
If there is a list of accessibility issues available, skip to Stage 2. If not, go to step 2.
Step 2
If there is no record of any accessibility issues with your material, check that there are HTML versions available. Some formats, such as PDF, should be avoided as they are not accessible for those using screen readers.
If there are HTML versions available, skip to step 4. If not, go to step 3.
Step 3
Create HTML versions of your material or course. These should be produced using R Markdown, which is knit to an HTML. If you are creating presentations, go to the creating an accessible PowerPoint template section.
Convert Jupyter notebook content for Python into R Markdowns, which support Python code. This is a manual task and can take some time, but it will only need to be done once, which makes maintenance and updates much easier to complete.
There is a function called convert_ipynb(), which converts a Jupyter Notebook into an R Markdown. This could significantly reduce the work involved in this step, but there are a few caveats.
Step 4
Paste the HTML document’s URL into the wave webaim tool to obtain a record of the accessibility issues in the HTML. The tool will respond with a list of the Web Content Accessibility Guideline Errors (WCAGE).
The tool reports issues that would adversely impact anyone using a screen reader. Before using the R package or making edits to presentation templates, save this information into a word document to review and keep as evidence of the issues.
Step 5
Check the accessibility of your Word document (.doc) files. These are widely used and preferred over PDFs, but they can also present accessibility issues.
Navigate to the ‘Review’ tab in Word, where you will find a “Check Accessibility” button. For more information, see Microsoft’s guidance on Word document accessibility.
Creating an accessible PowerPoint template
PowerPoint presentations are widely used in training courses, updates, show-and-tells and outreach events. To ensure your presentations are accessible, start by following steps 1 and 2 on S. Then, proceed with the following steps:
Step 1
Check if your organisation has a template for presentations. If there is a template, skip to step 3. If not, go to step 2.
Step 2
Create your accessible PowerPoint template. Once this is approved by the head of your department, skip to step 4.
Step 3
Evaluate the accessibility of your organisation’s existing PowerPoint template. Check the Microsoft PowerPoint guidance on checking accessibility.
The Review tab in the ribbon has a “Check Accessibility” option that will display issues with your template, which should be pasted into a Word document. This tool can also be used for ad-hoc presentations, if necessary.
Step 4
Use Microsoft support to address as many accessibility issues as possible.
Step 5
Present and circulate the accessible template across your organisation to gain feedback, inspire and encourage others to improve accessibility in their department.
Stage 2 – solving existing accessibility issues with accessrmd
Now that the paper trail has been established, you can begin solving accessibility issues using the R package “accessrmd”. Our GitHub repository and blog post have more detail about the functions contained in the package and examples of their use.
Step 1
If you are going through a curriculum review or update, complete this in R Markdown and confirm changes with stakeholders and your wider team before presenting the finished product.
Remember to use convert_ipynb() or a copy and paste process for Python notebooks.
Step 2
“Knit” your final version to an HTML page, which will form the final course notes. Knitting is the process of converting a code script in R Markdown to an HTML webpage.
Use the naming convention “previousname_pre2022.html” so there is a clear comparison with the newest version.
Step 3
Install “accessrmd” from CRAN into your R environment using the code ‘install.packages (“accessrmd”).
This only needs to be done once and from there on, it can be imported to a session of your choice using the code “library(accessrmd)”.
Step 4
Apply functions from “accessrmd” to your course markdown and save the output as a new HTML with the naming convention “previousname_2022.html”, so that it is easy to distinguish between them before and after the curriculum review.
Step 5
Test the new HTML in wave webaim and create a new Word document detailing the existing issues that “accessrmd” has no functions to solve (or issues that were supposed to work but didn’t).
This allows for maintenance documentation, as well as a paper trail for when new additions to this package are released in the future.
Step 6
You are now ready to upload and distribute the final course materials.
Stage 3 – continued development and maintenance
This stage applies to everyone at your organisation and can be led by an accessibility champion.
Step 1
Commit to regular accessibility audits in line with current guidance on accessibility of HTMLs and presentations for screen readers.
Maintain good collaboration and discussion with other departments and stakeholders around accessibility. Organisations such as the Digital Accesibility Centre (DAC) can test materials, provide accessibility audits and roadmaps, as well as updates in the field.
Consulting with disability groups at your organisation could lead to a “focus group” where discussion and testing can take place.
Bring new developments to the attention of the accessibility champion. That way, they can be collated in advance of the next audit or curriculum review, and multiple issues can be fixed at the same time, if resources allow.
There should be at least one audit for accessibility purposes each year. This document will serve as a guide for each subsequent review. If there are no new courses to be added or written, begin at stage 2.
Step 2
There is an ongoing process to make improvements and resolve new issues with accessrmd. The package is functional and incredibly impactful, but there are some unresolved issues and potentially unidentified problems.
New updates to the package, as well as issues solved, will be included in its documentation.
This should be checked during each subsequent audit to ensure that the newest version can be used to further improve existing documentation.