dwp / accessibility-manual Goto Github PK

There is nothing in the guidance for your job role about the use of REM and EM for font sizes and WCAG 1.4.4 Resize Text

A lot of the content was written quickly and could be simplified using Hemingway App

The yellow highlight looks too much like the focus indicator. There will be a better way to highlight the areas of interest on the images in a way where they don't look like they have the keyboard focus.

HighlightJS9 is at end of life and needs updating

Hi there,
I'm from the Digital Accessibility in Learning team from the Canada School of Public Service (a Canadian Department) specialized in creating and delivering learning products. We're currently revamping our accessibility section in our Playbook and we'd like to collaborate with you.

Let us know if it's something possible!

Thanks,
Myriam Lamontagne
Senior Instructional Designer in Digital Accessibility
UX Division
Canada School of Public Service / Government of Canada
[email protected]

As seen on https://www.accessibilitymanual.com/accessibility-law/the-public-sector-bodies-accessibility-regulations-2018

I suspect your Markdown to HTML parser is treating every \n as a linebreak. The HTML it produces is:

<p>Sometimes there is confusion between what is a website or a computer programme.
<br>
For the purposes of the legislation, a website is anything which runs in
<br>
a web browser.</p>

Files affected: https://github.com/dwp/accessibility-manual/search?q=for+the+purposes+of+legislation

On 30 August the digital accessibility specialist role was added to the DDat profession.

Could this please be added to the manual please, happy to assist in adding content for the relevant pages of the manual.

Best,
Adam

Please note - this is my first interaction with GitHub so I apologise in advance if this is out of place.

https://accessibility-manual.dwp.gov.uk/best-practice/designing-screens

two links (at bottom of page)

• interaction designer
• content designer

Both links go to interaction designer advice. ie. content design link is incorrect.
Looks like content designer link should be: https://accessibility-manual.dwp.gov.uk/guidance-for-your-job-role/content-designer
As i can navigate to that page by changing the Url, or find that link elsewhere on the site.

The site is great but the way. Just used it to help a couple of colleagues out - show that the law means internal systems have to be accessible and publish an accessibility statement.
I'm telling people this is the de-facto site for Gov accessibility advice.

https://accessibility-manual.dwp.gov.uk/guidance-for-your-job-role/software-engineer-or-frontend-developer
Timeouts section says
"the default time limit is set to at least 20 hours"

Shouldn't this be minutes, not hours?

The jump link for labels and instructions doesnt work.

Check ID and href values

I love WebAim. They are great. No problem with you promoting their terrific work:
https://accessibility.civicactions.com/guide/tools#quick-tests

That said, we're promoting two other tools for color contrast because they are open source:
https://accessibility-manual.dwp.gov.uk/tools-and-resources/manual-accessibility-testing

The other big advantage of https://contrast-ratio.com/ is that it can take more than HEX values. HSLA works well in the web & transparencies are increasingly important.

on https://accessibility-manual.dwp.gov.uk/tools-and-resources/basic-accessibility-checks/1-automated-tools-how-to-test

should go to:
https://accessibility-manual.dwp.gov.uk/best-practice/automated-testing-using-browser-plugins#axe-devtools

currently goes to:
https://accessibility-manual.dwp.gov.uk/best-practice/automated-testing-using-browser-plugins#arc-toolkit

I am looking at https://accessibility-manual.dwp.gov.uk/best-practice/wcag-aa-and-aaa

And I'm not sure that's the right approach. I think at this point it is useful talking about WCAG 2.0, 2.1, 2.2 & 3.0.

It isn't clear from this document that WCAG 2.0 requirements are included in WCAG 2.1 (but they are).

AAA should be aspirational, and AA the legal floor. Every government site should be AA, and depending on the audience of the site it may be important to prioritize which AAA criteria a department strives to achieve. You kind of get to this in the document but to meet WCAG AA, all WCAG A requirements need to be fulfilled.

This might be accurate:

Some of the impacts of making your service AAA will involve changing how a user interacts with your service and will go against security and GDS patterns, however, some will be fulfilled by default.

But folks seeing this will just stop reading any further. If there are specifics about AAA requirements that go against GDS & security best practices, be specific. There should be an issue queue somewhere to track current best practices to addressing this.

I'm not sure this is the best way to express this either:

We have a legal requirement to meet AA, however to meet AAA we have to meet every single one of the WCAG 2.1 criteria.

I don't think a government website exists that can claim to be AAA compliant. Certainly the W3C isn't. Being WCAG 2.x AAA compliant is next to impossible, and considerably increases the costs of building and maintaining a site. Not that those aren't worth striving for, but nobody should be talking about AAA compliance, as it doesn't really exist.

The page https://accessibility-manual.dwp.gov.uk/tools-and-resources/basic-accessibility-checks links to an XLXS and ODS file, both links appear to be wrong though.

Current links:
https://accessibility-manual.dwp.gov.uk/public/docs/Basic-Accessibility-Checks-v2.0.0.xlsx
https://accessibility-manual.dwp.gov.uk/public/docs/Basic-Accessibility-Checks-v2.0.0.ods

Looking at the files in the repo it looks like they should be:
https://accessibility-manual.dwp.gov.uk/public/docs/basic-accessibility-checks.xlsx
https://accessibility-manual.dwp.gov.uk/public/docs/basic-accessibility-checks.ods

This list of courses might be useful:
https://github.com/accessibility/a11y-courses

There is a lot of redundancy:
https://github.com/accessibility/a11y-lists-of-lists

If there is a way to point to other lists this can be helpful. Ultimately we need a community to maintain these ongoing activities.

2 big events though:
https://globalaccessibilityawarenessday.org/
https://www.un.org/en/observances/day-of-persons-with-disabilities

Lots of packages outdated and Node 2 v behind

GDS plan to review the content in the manual and the content on GOV.UK just to make sure everything is aligned. Once the review is completed I will schedule in any updates.

Unlike in the software engineering section, the content design section it doesn't mention the page title format:
page title - service name - gov.uk

This is because it was assumed that the content designer would need to title the pages, and the service name, but the software engineer would have to configure the title format in the layout.

However, on reflection, it should probably be called out in both sections so it's consistent and incase it gets missed.

I am biased but the videos from Accessibility Scotland are worth a watch (and possible inclusion!)

This page - https://accessibility-manual.dwp.gov.uk/best-practice/document-structure - like the rest of the manual contains some really great stuff. Lots to build on and learn from.

Language

Could be improved by explaining about the language of parts. It is a bit technical here, and many WYSIWYG editors may not have an easy way to insert a language attribute into it. We have built it into Drupal, but even there it isn't enabled by default, and not something that a generic editor can enable. More examples here will be useful, as most folks won't know how to hard code the HTML for Je Ne Sais Quoi. This isn't something that people are trained to do in my experience:

If you have more than one language in your document, for example you have an English document which contains a French quote, then you should make sure you set the language correctly for each part.

It is common to say, "You should try to write in plain English and for a reading age of 9." but if you put the line above into https://hemingwayapp.com/ it shows as Grade 14. We all do this. Plain English is hard to write. It is important to have some automated process to check.

I also like to remind folks that we're writing for real world situations. People are reading work email after have a drink or two with friends at the pub, while on their cell phone. We can't assume that people reading this content are at the top of their game and have already have their 2nd cup of coffee in the morning. Real world, especially in a pandemic, is more complicated than that.

It was unclear to me what type of documents you were writing..

The only office tool I know that has accessibility checkers built-in is the one from Microsoft, so you might as well say that. If government uses other software that has it, it would be good to include it.

Also, on PDFs, can you be clear and consistent and tell people not to? We know they will do it anyways, but ya, a warning like this one would be good.

Plus, why not link to the great work over here https://www.gov.uk/guidance/publishing-accessible-documents

Feedback from interaction design that there is no links to guidance for learning voiceover to test prototypes

Hi

W3C provide a free accessibility training course - https://www.w3.org/WAI/fundamentals/foundations-course/ - which you might like to add to https://accessibility-manual.dwp.gov.uk/tools-and-resources/free-events-and-videos

1. Open https://accessibility-manual.dwp.gov.uk
2. Click "Tools and resources" (https://accessibility-manual.dwp.gov.uk/tools-and-resources)
3. Page not found

Just following on from ARIA attributes not allowed on conditional reveals

This no longer seems to align with alphagov/govuk-design-system-backlog#37 (comment), so I assume should be updated?

On the page The Public Sector Bodies Accessibility Regulations 2018, under the heading "The 2022 Public Sector Bodies Accessibility Regulations amendment" there is an instance where the word "Accessibility" is spelled "Accessblity".

On https://accessibility-manual.dwp.gov.uk/guidance-for-your-job-role/qa-tester the "manual testing using tools" link under the heading "Manual accessibility testing", goes to "Page not found".

I assume it needs to go to https://accessibility-manual.dwp.gov.uk/tools-and-resources/manual-accessibility-testing

We have a bigger list of known issues which are not shared in the manual.

location: https://accessibility-manual.dwp.gov.uk/tools-and-resources

Broken link to "Automated testing"

Add the HTML template for step by step guidance on voiceover

EN 301 549 has a newer version than the one we're currently linking to.https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf

The page here:
https://accessibility-manual.dwp.gov.uk/best-practice/assistive-technology-testing

should have a title of (missing an 's):
Assistive technology testing

I think i've you'd been using tools like this that spelling error would be caught:
https://accessibility.civicactions.com/posts/how-we-scale-inclusive-website-content-with-automated-testing-and-open-source-tools

I do this myself sometimes, so noticed:
"screenreaders" should all be "screen readers"

The paragraph:
Every page should be tested using common screenreaders. If you’re using Apple devices you can use Voiceover for free, and if you’re using Windows then you can use NVDA for free.

Would be improved (I think), if it were:
Every page should be tested using common screen readers. If you’re using Apple devices VoiceOver is built-in. If you’re using Windows for testing we recommend installing the open source [NVDA](https://www.nvaccess.org/) screen reader for free. NVDA has become one of the [most popular screen readers](https://webaim.org/projects/screenreadersurvey8/) and although it is less powerful than JAWS, it is better for catching many accessibility errors.

There is still a preference for JAWS, as it is what governments are used to testing for. There are good reasons why testers should be focusing on NVDA though.

This is mostly in /app/views/best-practice/assistive-technology-testing/partials/screenreader-testing.md

Add the HTML template for step by step guidance on NVDA

The mobile menu has a static 0 in the ID rather than using the Nunjucks iterator.

The current acceptance tests for broken links look for 200 responses, but this causes some jump-links to pass when they should fail. We should write separate acceptance tests for jump links and make sure the page navigates to the correct headings.

In /best-practice/agile-teams#alpha, there's an opportunity to talk about risky assumptions related to access needs.

I'd suggest linking to the relevant page in the Service Manual, and also giving some examples of accessibility related assumptions, with some content about how to find and rank risky assumptions

Proposed content:

In Alpha, you should focus on testing your riskiest assumptions. You should take that approach with accessibility too. That means you don't need to test in Alpha with every single access need, just the ones that are most risky for your service. For example, one of your assumptions could be "Users who use screen readers will be able to access the content". If your service exclusively uses design patterns which are tried and tested, that particular access need may not be risky. But if your service uses more unique interactions, it may be more risky and so this assumption would need to be tested in Alpha.

Start by working out your accessibility assumptions, by working out which access needs would affect the use of your service the most. You could use the posters made by the Home Office as a starting point. Next, rank each one of these in terms of their risk level. Finally, test those assumptions and iterate your design until your confident that the risk level has gone down.

The jump link in the sidebar for the WebAim checklist is broken.

Conversation around whether number 2 needs tweaked so that it is clear that accessibility is not always about people using tools. The last sentence should perhaps be re-written to say 'if' or 'whether' they use tools

2. Accessible design is good design

Good design should meet needs and solve problems. If you design something which is inaccessible you will create barriers for people. Good design is not just what looks good, it must be usable. It must work for everyone, regardless of what tools they use or what impairments they have.

This guide is great, I'm going to share it internally. One minor thing I noticed is that when the window is resized the columns on the homepage begin to overlap. Not sure if breaking over lines or switching to a single column sooner is the answer but thought I'd let you know!

(Firefox 83.0)

I love this initiative. I think the content is great and the guidance is useful.

But...

Why is this on a .com domain? Part of the success of modern digital government is about having a single, trusted domain. Here are my concerns:

1. How long has this .com been registered for?
2. What are the decommissioning plans?
3. Has The National Archive been involved in preserving the content?
4. How much is this costing to register and host?
5. Is there any indication that this is a genuine service?
6. What are the risks of a scammer registering accessibility-manual.com and trying to deceive your users?

As I say - this is brilliant work. I'm just concerned about the proliferation of domain names, and the unintended consequences that go with them.

hi, thanks for the creating the accessibility guide, it's excellent. On this page https://accessibility-manual.dwp.gov.uk/guidance-for-your-job-role/content-designer the hyperlink to Office for National Statistics data is not active.

On this page:
https://accessibility-manual.dwp.gov.uk/best-practice/manual-accessibility-testing

Provide more context here on how to do keyboard testing:
app/views/best-practice/manual-accessibility-testing/partials/keyboard-only.md

Webaim does a good job explaining how to do keyboard only testing. This one from NN/g is pretty good too https://www.nngroup.com/articles/keyboard-accessibility/

As part of your manual tests you need to make sure the page works as expected using [just a keyboard](https://webaim.org/techniques/keyboard/#testing). Every part of the page must be able to be viewed, and every interactive element must be usable.

As a Delivery Manager you need to make sure that accessibility is considered when sizing up stories and that very feature is fully accessible before it is released.

'very' should be 'every'.

Raised by Simon Hurst via Slack.

https://accessibility-manual.dwp.gov.uk/guidance-for-your-job-role/delivery-manager