Update the GC Notify Accessibility Statement

[mtoutloff]

Description

As a user I need to understand GC Notify's approach and commitments to accessibility on their website, and be up to date on known issues and have the ability to provide feedback.

As a public servant using Notify, I need to understand what steps Notify has taken toward accessibility so that I can feel confident in the product and understand how to raise accessibility issues.

WHY are we building? To refresh the accessibility based on the findings of the OCADU audit and to create form to report an accessibility issues
To provide our users with information about the accessibility of Notify. CDS unpublished its a11y handbook. We could update it and make our own, and not call it a handbook

WHAT are we building? An updated accessibility statement An up to date and easy to read and scan accessibility statement, including parts of the CDS a11y handbook that are relevant to share.

VALUE created by our solution We build our users confidence in our commitment to accessibility and our willingness to address new issues that arise.

Documentation and Artifacts

Good docs, figma mockups, ADRs, screenshots etc. Current version in prod Folder: https://drive.google.com/drive/folders/1eqV8fb_rLC_elxKi13L34TDSgm3qBGD3

Acceptance Criteria

Given I need the service to be accessible, when I want information about Notify's accessibility, then I can easily find the accessibility statement and the statement answers my questions.

MAYBE: Given I find an accessibility issue or problem with the GC Notify product, I know how I can give the team feedback

• [x] Draft updated accessibility statement and feedback form

• [x] Content review

• [x] Check that "Known issues and limitations section" is current

• [x] As we'll be mentioning taking user feedback, update privacy statement to let members of the public know that we collect their feedback, conduct user research, etc.

• [x] Translate accessibility statement and changes to privacy statement

• [x] Enter in GC Articles where font size, color and tables will be different so revisit accessibility of those once we're getting ready to publish

• [x] Publish accessibility statement and changes to privacy statement

• [ ] Update clients on the new accessibility statement and if necessary, changes to privacy statement

• [ ] Share with broader Platform community

• A11y

• Bilingualism

• Privacy considerations

• Measuring success and metrics

Related Research Airtable records

• (Ping Adrianne to add stuff here or find stuff yourself)

QA Steps

• [ ] Tested in a realistic production scenario

GC Articles Publish checklist

• [ ] Supporting feature is released and unflagged
• [ ] Create or update slug
• [ ] Page content and slug is translated
• [ ] Document links to and from the page
• [ ] Add page slug and title to inventory
• [ ] If new page, add WAF rule
• [ ] Create new page or update existing page content
• [ ] Create or update translation to the page
• [ ] Link translations by choosing an assigned translation
• [ ] If new page, save as draft
• [ ] If existing page, update the page
• [ ] Post page in Slack for last minute reviews
• [ ] On staging: Clear the cache through GC Notify's admin panel
• [ ] On staging: Check links, images and language toggle
• [ ] Give a heads up to the app-team channel once ready to publish
• [ ] On staging and production: Clear the cache through GC Notify's admin panel
• [ ] Clear Cloudfront cache in GCA as needed (Andrew and Phil are GCA admins)

[amazingphilippe]

This doesn't have to be the official doc, but I started thinking about some details form an a11y perspective: https://docs.google.com/document/d/1WKUwufZVvFKQzNfclzZ9Gtc7yAw0eiC6dJvXN58uTR0/edit?usp=sharing

[YedidaZalik]

W3 info on developing an accessibility statement, they also have a generator to create statements:https://www.w3.org/WAI/planning/statements/

It appears that CDS, GC Forms, GC Design system and Canada.ca do not currently have accessibility statements, but ESDC does and their feedback form includes privacy considerations https://www.canada.ca/en/employment-social-development/accessibility.html

[yaelberger-commits]

Hey team! Please add your planning poker estimate with Zenhub @mtoutloff @YedidaZalik @amazingphilippe

[mtoutloff]

At Sprint Planning: Report accessibility issue form will be out of scope for now. Will focus on updating it with known issues and look at example Yedida provided above. Once finished, I will share with rest of Policy Team and possibly broader Platform community as an example other products can adopt.

[mtoutloff]

Met with Phil, Yael, and Yedida to discuss how to update the statement

[mtoutloff]

Started work on updated outline for the Accessibility statement. Went over it with Yedida and Phil reviewed and provided comments.

[amazingphilippe]

Melissa and Phil to sync and find sources

[mtoutloff]

Met with Phil last Thursday to discuss content. I will start working on drafting the content today

[YedidaZalik]

Melissa and Yedida in process of finalizing privacy statement changes

[mtoutloff]

Melissa and Yedida working on updates to the accessibility statement

[YedidaZalik]

Yedida will re-word /re-organize in this doc It includes the notes on non-compliance from both IDRC reports (2023 and those from 2022 that Phil has indicated are still issues) https://docs.google.com/document/d/1NP2EaXnvo81SKL31zlSOgMmW8lnH8HnQysy7SLMbKW4/edit

[mtoutloff]

@YedidaZalik still working on content and expects to finalize early next week

[mtoutloff]

Yedida will use head's down time to today to make progress and take to content critique tomorrow morning

[YedidaZalik]

Feedback from this morning's content critique

March 19, 2024 Content critique

Used WCAG statement generator and took inspiration from UK statements

Known issues - there are many WCAG include the numbers and the names? or How to organize? Still need to simplify?

Programmatic

Helpful to have WCAG numbers is helpful Could you have subsections with plain language headings for each issue and then have number ref and other explanation beneath - very specific - have the xplanation up front in plain language

Who is the audience - if outlining for public servants - link to WCAG and when to be addressed (roadmap)

When will the address will be addressed

Make clear that one is for end users - did not list WCAG number

Inspiration from Accessibilty reports - numerical order for main categorises - use the four buckets from WCAG

CTA to help team address the issues

Break up the bullets - one with many bullets Splitting those out to group smaller number to gather — break them into smaller bullets

Perhaps this statement from Accessible Canada could also be inspiring https://accessible.canada.ca/accessibility-statement

Marketing/comms —talks about issues — successes where WCAG is exceeded - way to highlight or balance the text that way But focus should be on known issues

Say that explicitly - say the purpose of the statement

2 needs (marketing side - most shared blog is approach to making platform accessible - once you’ve decided to use these are the shortcoming and how you’ll address -

I wonder if another audience is compliance/QA teams

Reverse order so under Known issues - say upfront what system does and then give the tools the user can rely on and then say what it does not do - say first what it does and then what it does not do

[YedidaZalik]

Covid Alert statement https://docs.google.com/document/d/1FY8172uqEXTfkZCUMgT0R-gfOye9XAJslgPv2WwL5qo/edit#heading=h.f6rxtpxsjnsz

Also inspiration from GC Forms blog post https://articles.alpha.canada.ca/forms-formulaires/why-gc-forms/ https://digital.canada.ca/2023/02/16/how-were-building-gc-forms-our-4-accessible-approaches/

[YedidaZalik]

@amazingphilippe and @YedidaZalik reviewed zenhub for additional Ally issues. Left off at #494 to continue tomorrow.

[mtoutloff]

There are more issues than expected, so we need more time, and Yedida will share with Melissa the main issues

[YedidaZalik]

Write-up for policy discussion: Ally points for Policy

[mtoutloff]

Contacted the ESDC centre of expertise on accessibility to see if they could help us with our statement. Were directed to the IT Accessibility office and are waiting to hear back back

[mtoutloff]

Yedida will be putting the issues into plain language this week Also discussed last week with team and Ioana and Mohamed that since there are a lot of issues we will make accessibility issues a priority

[andrewleith]

• Contacted some experts at ESDC, followed up but haven't hear back
• Waiting to see how many issues we can fix this sprint

[YedidaZalik]

IT Ally office directed that their Comms folks should review statement Asked if usability testers for Alt text and waiting to hear back on that Yedida will work on it today

[YedidaZalik]

Lots of progress and will continue on it

[YedidaZalik]

Took draft statement to Tuesday content critique Implementing feeback today

April 23, 2024 Content critique questions CTA to help team address the issues I like this idea, I’m not sure how to do it without it being repetitive or not clear that it’s a deficiency, idea Amy - enumerate them and common categories - list and where 2 or more a /b and part 1 part 2 as sub level when you number things could imply one more important but may not be implication in long list checklist

Anik - Emphasis is on more important aspect with WCAG as supporting

Ordering principle and what might apply - single a double a

CTA - looking at now more framed around limits Could be work around

Alexa ways to break list into smaller sections - a lot of text still so if opportunities to help people scan because so much bold

Amy WCAG difficult to understand, but these are clear, avoid “should” and in this context it’s appropriate

Charlotte -section, header and context and WCAG —bolded line could be H4

Another way to group some of the issues - - hard to use with screenreader limitations if using screen reader, navigating with keyboard, many span multiple modalities

Chelsey asked about this content in the statement (I'm still working on the wording): Recipients who use assistive technology may have difficulty with emails from GC Notify This is because: Screen readers do not always read text in the correct language (WCAG 3.1.2 Language of Parts) NVDA announces extra spaces in Microsoft Outlook. (I need to figure out which WCAG #) Headings within the email start at h2 instead of h1 (WGAG 4.1.2 Name, Role, Value) And how that content fits with this line on the Notify home page: Send consistent and accessible email messages from a trusted domain. Are we giving departments an incorrect impression by stating that emails sent from Notify are accessible

[YedidaZalik]

Met with Phil and Melissa about possibly organizing issues in this way

Also discussed that we don't need to follow this guidance on citing/referencing WCAG How to refer to WCAG from other documents Referencing and linking to standards (less relevant)

[YedidaZalik]

Went to content critique to ask if any way to make lense dense; feedback that probably not but Amy suggested could try table with columns or icons/imagery and WCAG criteria on one side Discussed linking with Charlotte before others joined, best to link to short version of requirement for reader to choose more info in bite snack meal style

Yedida checked Ally stmt content against Github board

[YedidaZalik]

Following critique tried columns suggestion here https://docs.google.com/document/d/1saW4CgTZ1h2Nf42o0l5L1KSPc6QqWYav5fVZ9ByLbQ8/edit#heading=h.okcnztcgroyx

Liked it better and moved into Draft statement We can go back to earlier version if others prefer

[YedidaZalik]

I've purposely made the first column wider for emphasis. UK Notify Ally's statement has now fixed the date to say it was last updated today. In addition to explaining how to give feedback, they indicate how to make an enforcement complaint. I think it would be good if we could include that info as well, if we have an office to complain to? The draft statement is ready - it's lengthy and may take awhile to review. Asked if Phil, Melissa & Yael have enough time to review this week so I can implement feedback on Monday

[YedidaZalik]

While statement is in review, Marie-Sophie will work on FR changes to Privacy statement

[YedidaZalik]

I'll start implementing feedback on the Ally statement today. Wherever it's not straightforward, I plan to implement using the suggest function. Then I'll tag Melissa in the comment, and if she's good with my suggestion she can accept the changes and resolve the comment. There maybe some comments where I also tag Phil and Yael and Melissa might also tag someone.

[YedidaZalik]

Feedback has been implemented. Phil tagged on some items and now also asking MSB to review. Will run any changes suggested by MSB by Melissa.

[yaelberger-commits]

With MSB for localization review Yedida and Phil will meet this afternoon to remove resolved issues

[YedidaZalik]

Went through and removed resolved issues with Phil MSB reviewed this morning. Implemented her comments and Melissa approved the changes. Ready for localization. MSB says she can have it ready for May 20 so we can have it up for STT that week.

[YedidaZalik]

Went through and removed resolved issues with Phil MSB reviewed this morning. Implemented her comments and Melissa approved the changes. Ready for localization. MSB says she can have it ready for May 20 so we can have it up for STT that week.

[YedidaZalik]

MSB completed changes for Privacy statement here: https://docs.google.com/document/d/1wSwn7EauBcaVm9wZ5Dn6s1ZXHBlOBrvc5Ud3T2Y9EGM/edit#heading=h.q86bolk1xr4p

I created pages for archived versions and updated current version. After clearing cache, all changes showing except links to previous version - Andrew fixed that

[yaelberger-commits]

I QA'd both EN and FR Privacy notices to verify all changes were made correctly and no typos in production. LGTM!

[YedidaZalik]

Made archived versions of current A11y statement FR of A11y statement is done https://docs.google.com/document/d/1rCfi6UOclDP1dYn9arnE3peVlbQ8f70I0subnXuihCw/edit Will update new statements tomorrow

[YedidaZalik]

Met with Pete - google doc of A11y statement looks accessible Once it's up on GC Articles, ping him and he'll test it

[YedidaZalik]

Pete kindly tested the live EN statement, and says we can improve the accessibility of the statement itself by moving the table columns that are headings into a element. Also it’s not possible to insert bullets into the details dropdown, so I had to use dashes. Pete says that's probably the best work-around for now. I will document these items to be addressed in v2 in a new card @yaelberger-commits will proof against EN and FR drafts

[mtoutloff]

Updated the main Policy doc to include updates to the Accessibility Statement