Create a Guide/Template: UX/UI Accessibility Standards

[daniellex0]

Overview

We need to create a guide for UX/UI Accessibility so that designers at Hack for LA can ensure their projects follow accessibility standards

Action Items

The phases in the guide-making process are listed below. Each phase displayed in blue is linked to a wiki page with instructions on how to complete that phase. Open the wiki page in a new tab, copy the instructions for each part into the section labeled 'Tasks' at the bottom of this issue, and complete each task listed.

• Gather Examples Solo (open in a new tab)
• Gather Examples Collaboratively
• Create a Guide Draft
  • If needed, create a template
• Have your guide peer reviewed
• Present your guide for leadership review

Resources/Instructions

• Google Drive Folder for this Guide’s documents and shortcuts (to documents in other locations)
  0134 UX/UI Accessibility Standards

• Draft How to UI/UX ACCESSIBILITY GUIDE - LAST UPDATE 08-13-2021

• Basic guidance for wcag website compliance

• accessibility guidance as part of the Design Systems project research

Projects to Check

Tasks

• This is where you will copy instructions from the wiki page for the step you are currently on.

[ExperimentsInHonesty]

Previous Draft as of Feb 23, 2021

Overview

There are more than 100 accessibility testing tools. Figuring out which ones to use can be a black hole. For guidance we recommend this article: Which accessibility testing tool should you use?

Summary of Article

The author recommends using the tools in the following order fixing as you go along, since no one tool catches all the relevant issues

aXe
SiteImprove
Tenon
WAVE
Lighthouse

But if you want to test your site with other tools, here is a bigger list

---

Lighthouse Guides

Lighthouse: How To

Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, and more. Hack For LA recommends that you run the tests and evaluate what changes you might want to make on your website to improve performance and accessibility.

How To Use

Lighthouse is in the Audits panel of the Chrome DevTools. To run a report:

1. Download Google Chrome for Desktop.
2. In Google Chrome, go to the URL you want to audit. You can audit any URL on the web.
3. Open Chrome DevTools.
4. Click the Audits tab.
5. Click Perform an audit. DevTools shows you a list of audit categories. Leave them all enabled.
6. Click Run audit. After 60 to 90 seconds, Lighthouse gives you a report on the page.

For more information go to :
https://developers.google.com/web/tools/lighthouse/

Tip

You will want to re-run lighthouse on any code changes before integrating them into your site. Sometimes the specific suggestions it makes, do not actually result in improved performance or can actually harm performance.

---

Lighthouse: Accessibility - Forms

In order for your sites form(s) to be usable by visitors using screen readers all the form elements need labels. There are specific details and exceptions, which can be found in the instructions below.

Action Items

If your site already has forms review the instructions and document the changes needed to bring your form(s) into WCAG compliance, by commenting on this issue.
If your site does not have forms review the instructions and design new forms using the WCAG standards.

Instructions

Deque University
https://dequeuniversity.com/rules/axe/3.2/label

---

Lighthouse: Accessibility - Links

The formatting of links can make them readable or unreadable by screen readers. Which includes creating programmatic events for links without making them device specific (e.g., onfocus() instead of onmouseover(), etc.), and other ways of making sure all links are visible by screen readers.

Action Items

If your site already has links review the instructions and document the changes needed to bring your link(s) into WCAG compliance, by commenting on this issue.
If your site does not have links yet review the instructions and design all new links using the WCAG standards.

Instructions

Deque University
https://dequeuniversity.com/rules/axe/3.2/link-name

---

Lighthouse: Image Optimization

When you run the lighthouse review it may suggest some specific image optimizations such as choosing another image format and making those changes may or may not improve your sites actual performance.

Action Items

Run lighthouse on a local version of the website and then apply suggested changes and retest locally before determining if you want to keep the changes.

Instructions/Resources

Google's Tools for Web Developers: Optimize Images
Read closed issue hackforla/UI-UX#111 from when HackforLA.org did our audit, to see why we decided not to do the image optimization

---

Lighthouse Issue: Cross-origin destinations are unsafe

Links to cross-origin destinations are unsafe both from a security and performance perspective.

Action Item

Run Lighthouse and then follow the instructions in [cross-origin destinations are unsafe]
(https://developers.google.com/web/tools/lighthouse/audits/noopener) .

Summary of instructions

When using target=_blank also adding rel="noopener" to the tag ensures that new page runs in a separate process.

---

Wave Guides

Wave Chrome Extension: Accessibility review

Action Items

1. add WAVE chrome extension
2. visit site
3. click the extension and review the red flags.
4. Run the same steps for the development site (localhost). Ensure that the chrome extension has the "Allow access to file URLs" enabled.
5. Document all suggested changes in the comments.

[ExperimentsInHonesty]

Hi @salmonciara Do you want to keep working on this? If so we have a new guide template you can put your drafts into. Please let know, by replying in a comment on this issue.

[salmonciara]

Hi @ExperimentsInHonesty, I was adding accessibility content to "Second Draft: HfLA Design System Guide for Designers" for the Design System Project @Hanastevenson is managing. Is that the new guide template you are referring to?

[ExperimentsInHonesty]

Hi @salmonciara the Guides team asked Hana to review all the Hack for LA "How To" guides that were in progress (before the design systems project started) and this guide was one of them. Here was her answer when we asked if this guide was still necessary:

Hana and Danielle said;

"There are accessibility guidelines in the Design Systems guide, but it would be good to have a dedicated accessibility guide with even more details. Whoever is working on this guide can reference the accessibility section of our guide. Ciara Salmon is our dedicated Accessibility advisor, and is already attached to this Issue. Please discuss with her."

So what we we are trying to find out, is are you planning on taking the template for making a Hack for LA guide and the content in this issue and making that separate guide:

1. When Danielle orginally wrote issue she provided a link to

WCAG

1. on February 23rd Bonnie wrote a comment that included draft guidance for deciding what accessibility tool to use when testing code in your browser.

#134

1. on July 18th Alyssa Bryant wrote

@salmonciara Also has some accessibility guidance here as part of the Design Systems project research:
https://docs.google.com/document/d/1fUsbtr2m5oMhF_RkwDcEvl_3gykVsSXHWQC5EfAkoB4/edit

1. on July 20th Danielle wrote

@ujunwaa has created this document with some basic guidance for WCAG website compliance.
https://docs.google.com/document/d/1dFKJlIl5PGXzddXnm7dFCzFTReT8N9-HIq5DDvWlxQ8/edit?usp=sharing

This issue is assigned to you, so we are following up to determine if you are going to continue on this, or if we should un-assign the issue.

[salmonciara]

@ExperimentsInHonesty thank you for the context. I did not know this was assigned to me. I can create the guide for accessibility.

I can only give perspective from design for accessibility. I will try and recruit @qiqicodes for the developer perspective

[ExperimentsInHonesty]

@salmonciara thank you for the response. 🥳 😻❤️ I think given that this guide was in UI/UX it was intended to be the guidelines that designers use while designing. We are really in need of some specific guidance to how to design well before things reach development and developers start using the chrome extensions that help them evaluate the accessibility of the design they are given. I think it will be great if you talk to QiQi to get her perspective as long as it does not transfer the responsibility for accessibility design onto developers, which is what has been happening on our projects and is causing a lot of rework after development has completed pages.

[salmonciara]

@ExperimentsInHonesty Perfect. I already drafted up a guide. It is definitely still a draft so please keep that in mind if you are going to look it over.

https://docs.google.com/document/d/1oA3eHypGag_BbphTcUseKwaNWOvQ9gvClnWg2Atyqkk/edit?usp=sharing

I do have a section where I believe I will need input from developers as some accessibility audit tools provide code to be fixed. I likely don't need much work to be done on it, only how it can be best communicated from UX to Dev.

[ExperimentsInHonesty]

@salmonciara thank you for the draft! I have made some formatting changes to the beginning of the document can you continue that throughout and then let me know, so I can take another look?

[salmonciara]

@ExperimentsInHonesty I left a comment back on the font request.

[ExperimentsInHonesty]

Hi @salmonciara Here is the history of our communication on this issue. I am moving it here so that we can preserve it for future contributors and other people who need to stay informed on this issue.

Bonnie Wolfe, 7:49 AM Sep 10
Please change the font sizes for this portion to match the changes I have made above. The base font size should be 11 and the headings 16.

Ciara Salmon. 9:38 AM Sep 10
Accessibility standards state 16 font minimum. I would like the guide to reflect the standards we ask of designers

Bonnie Wolfe, 7:50 AM Sep 17
Thank you for pointing that out. There does seem to be a difference between Web and print. I was looking at some resources and it seems like we have a recommended 14-18. I know that when we port these guides to the web, the font size is bigger, and I will make sure that the design team that is working on this sees the draft of your guide before they finish their design specifications. Could we compromise on 14?

Here are the source resources I looked at to support what I am asking, in case you think any of these are inappropriate:

• https://www.semel.ucla.edu/sites/default/files/tarjan/pdf/TarjanCenterAccessibilityQuickGuide_May2015.pdf
• https://www.zaginteractive.com/insights/february-2020/making-your-printed-materials-ada-accessible
• https://www.perkinselearning.org/technology/blog/my-eight-favorite-free-fonts-print-disabilities

[ExperimentsInHonesty]

@salmonciara I realized after talking to @Hanastevenson that mostly people are not yet aware of the context in which we will use the current google doc.

We have designed a web version of the documents and will be converting all the finished guides the web format that does adhere to the same accessibility standards indicted in your guide.

Here is what this content will look like when its on the web (see the version in red box) https://www.figma.com/file/0RRPy1Ph7HafI3qOITg0Mr/Hack-for-LA-Website?node-id=15793%3A100646

We still will need the pdfs to be printable and they will link to the webbased guides. If there is guidance you can provide on printable standards we would greatly appreciate that before we go and fix all the current draft guides.

[salmonciara]

@ExperimentsInHonesty, Thank you for considering the larger font and reviewing other resources. I am in agreement with 14pt for the document and I will got in and update the document.

Thank you also for the background of where this project is going. I was not aware.

Yes, thank you for asking. My previous knowledge was that PDFs are not accessible as they are essentially an image which a screen reader cannot read and features such as font magnification does not work either. I did a quick search and there seems to be more resources regarding PDFs for accessibility. Let me do more in-depth research and get back to you. I will also reach out to the accessibility community to see if there is a preferred printable format.

[ExperimentsInHonesty]

@salmonciara Thank you! We look forward to your changes.

[ExperimentsInHonesty]

@salmonciara

We have another thing we would like you to weigh in on that is a bottle neck for us fixing all the guides. Do you have any information on what is best in these examples:

• Text or buttons that should be clicked/selected (e.g., Sign-In)
  Choose the Confirm button.
  Choose the Confirm button.
  Choose the Confirm button.
  Choose the "Confirm" button.
  Choose the 'Confirm' button.

• Text that the user enters word-for-word (e.g., user is instructed to enter xyz into this field)
  Enter "/Remind" into the field
  Enter '/Remind' into the field
  Enter /Remind into the field

• Text that refers to something on the page
  Their name and email will appear in the Waiting to be Confirmed header.
  Their name and email will appear in the Waiting to be Confirmed header.
  Their name and email will appear in the Waiting to be Confirmed header.
  Their name and email will appear in the "Waiting to be Confirmed" header.
  Their name and email will appear in the ‘Waiting to be Confirmed’ header.

• GitHub mostly uses bolding for selectable items and double quotes for where to put things and no text decoration for referring to a specific item on page: see 2FA example
• Twitch uses bold for selectable items and no text decoration for where to put things or bold, and no text decoration for where things are: see 2FA example

[salmonciara]

@ExperimentsInHonesty

To clarify, are you looking at the Gibhub and Twitch platforms standards on these items as these platforms are being referred to in guides?

Or is there another reason you are looking at these platform standards?

[ExperimentsInHonesty]

@salmonciara I am just looking at what industry standards are for technical guides. If there are other repositories of help files like figma
https://help.figma.com/hc/en-us/articles/360040328653-Use-shortcuts-and-quick-actions its worth consulting those for industry standards. Its not that they will override any accessibility recommendations, but rather if there is no definitive answer on accessibility, could be a fall back, or if there are two equally as valid options, then we go with what is most industry standard.

[ExperimentsInHonesty]

The Expunge Assist team wants to be notified when this guide is complete hackforla/expunge-assist#366

[Aparna1Gopal]

As per Instructions moving this to prioritized Backlog

[JesseTheCleric]

Assignee, Labels, Project Board Placement, and Milestones for this issue in the UI/UX Repo:

[JesseTheCleric]

Prior version of issue

###Overview
We need to create a guide for UX/UI Accessibility so that designers at Hack for LA can ensure their projects follow accessibility standards.

###Action Items
Research existing information about UX/UI Accessibility in relevant resources and articles including WCAG
Once done, remove the "Guide: Research" label and add the "Guide: Gather Examples" label
Gather examples of how other projects follow accessibility guidelines in their Githubs wiki/Readme (if any examples exist), adding each example as a link in the resources section below
Reach out to the UI/UX lead to find out if they did any Accessibility work that is not documented on the readme/wiki
Once done, remove the "Guide: Gather Examples" label and add the "Guide: Draft Guide" label
Create a draft guide, either in markdown format in this issue or a google doc in the [ux/ui google drive]
Once done, remove the "Guide: Draft Guide" label and add the "Guide: Review Guide" label
Review the guide with UX/UI community of practice
Once done, remove the "Guide: Review Guide" label and add the "Guide: Leadership Review" label

Present to the Hack for LA leadership team for sign off
Once approved, remove the "Guide: Leadership Review" label and add the "Guide: Place Guide" label
Resources
WCAG

Update issue #97 with the name of item you are working on

The Guide in the first comment of this issue is a starting point for instructions but will need to be customized and added to based on what projects actually use. Please do not delete the current draft, but rather copy and start a new draft.

Hack for LA's How To: Write a Guide

Draft HOW TO - ACCESSIBILITY GUIDE

[JesseTheCleric]

Files in this Issue:

Draft How to UI/UX ACCESSIBILITY GUIDE - LAST UPDATE 08-13-2021

• This file will need to be moved to the knowledgebase-content Google Drive

Basic guidance for wcag website compliance

• This file will need to be moved to the knowledgebase-content Google Drive

@salmonciara Also has some accessibility guidance here as part of the Design Systems project research

• This file will need to be moved to the knowledgebase-content Google Drive