Guide: UX/UI Accessibility

[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

• 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 #15 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

[ExperimentsInHonesty]

Current Draft

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 #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.

[abryant35]

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

[daniellex0]

@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

[ExperimentsInHonesty]

@salmonciara I had a great conversation with the HfLA website team today and found this article afterwards. Its related to the "Should we use strong (bold) and emphasis (italics) or quotes, etc. to denote instructions" Thought you would be interested
https://accessible-digital-documents.com/blog/banning-italics/

[ExperimentsInHonesty]

Text or buttons that should be clicked/selected (e.g., Sign-In)
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

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

[salmonciara]

@ExperimentsInHonesty

Thank you!! I will definitely include this in the accessibility guide.

I was hoping to have more time with Qiqi before she left as she has more resources on code specific accessibility. I have the accessibility principles of the output but do not necessarily understand what the code should look like or be.

[ExperimentsInHonesty]

@salmonciara oh, I thought QiQi said she would keep helping with the accessibility guide after she left running the CoP but I totally understand if she does not have the time. I can reach out to the developer channel to ask if there is someone else who has an interest in that area.

[ExperimentsInHonesty]

@salmonciara I just remembered I brought up the Strong vs Bold Emphasis vs Italics issue to the hackforla.org website team. So once they figure out how they will incorporate this guidance I will have Adam Abundas reach out to you on this issue.

[salmonciara]

@ExperimentsInHonesty oh perhaps I misunderstood when she was leaving what exact project she was leaving. I will reach out to her and ask her.

[ExperimentsInHonesty]

Bonnie said

@salmonciara oh, I thought QiQi said she would keep helping with the accessibility guide after she left running the CoP but I totally understand if she does not have the time. I can reach out to the developer channel to ask if there is someone else who has an interest in that area.

QiQi said

@ExperimentsInHonesty oh perhaps I misunderstood when she was leaving what exact project she was leaving. I will reach out to her and ask her.

@salmonciara were you able to talk to her?

[qiqicodes]

@ExperimentsInHonesty, @salmonciara and I spoke with each other three weeks ago.

I would love to work on the accessibility guide from the developer’s perspective. At this moment, I don’t have enough bandwidth to work on this guide.

[carolzjy]

This is very well written. The only remaining items seems to be making it conform to the guide template (which has changed a little since this guide was originally developed.

[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