The Problem Statement The American Red Cross "prevents and alleviates human suffering "in the face of emergencies by mobilizing the power of volunteers and the generosity of donors." The RCO and RCB platforms were implemented in 2018 without WCAG compliance and there has not been a concerted effort to implement the necessary changes since then.
We should do everything within our power to improve digital inclusion so that all our donors and volunteers are able to support the mission.
How will we measure success on this project? WCAG 2.0 success criteria are written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies, as well as general information about interpreting the success criteria, is provided in separate documents. See Web Content Accessibility Guidelines (WCAG) Overview for an introduction and links to WCAG technical and educational material.
What do we already know? Web Content Accessibility Guidelines (WCAG) 2.0 covers a wide range of recommendations for making Web content more accessible. Following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these. Following these guidelines will also often make your Web content more usable to users in general.
Web Content Accessibility Guidelines (WCAG) Overview: https://www.w3.org/WAI/standards-guidelines/wcag/
Mobile Accessibility: https://www.w3.org/TR/mobile-accessibility-mapping/
How to Meet WCAG (Quick Reference): https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0
- Chrome Dev Tools in-browser audit tool: https://developers.google.com/web/tools/chrome-devtools/accessibility/reference a. Check both boxes for Accessibility & Performance.
- Microsoft Accessibility Insights: https://accessibilityinsights.io/
- axe: https://www.deque.com/axe/
- Chrome
- Firefox
- Safari
- View open and available tickets in JIRA that are tagged with WCAG. These tickets will refer to a set of 50 urls that need to be scanned. To see the urls in the ticket, open the Red Cross sitemap spreadsheet and find the corresponding ticket in the JIRA column.
- Scan the urls with the assigned scanning tool and save the JSON results.
- Once all 50 urls in your ticket are scanned with all 3 tools in all three browsers. Note: if you are running Windows or Linux, you may need to download Safari 5.1.10 for Snow Leopard. You may also ask another Code4Gooder running a MacOS to assist in scanning your urls in Safari.
- Create a new file in the data folder located in the scan results folder using the naming convention in the documentation template below.Save all of your JSON results into your newly created file.
- When you are finished scanning and recording the JSON results, commit your work and put in a pull request.
- Post the link to the pull request in the comments of your JIRA ticket and change the ticket status to In Progress.
- In your local fork in the data folder located inside the scan-results folder, create a file using this naming convention: C4G-JiraTicketNumber_AuditToolUsed_URLNumber.json. For example: CG4-16_CD_7.json.
Audit Tool abbreviations:
- AT = allyTools
- AX = Axe
- CD = ChromeDev
- FF = Firefox
- IN = MS Insights
- WK = Safari
-
Inside your newly created file, copy in the JSON results from your scan.
-
Commit your work often, at least after adding new JSON data for each url.
-
Put in a pull request when you are finished scanning and saving results for all of the urls in your ticket.
This project was bootstrapped with Create React App. View here: https://rbitting.github.io/arc-accessibility-dashboard/
In the project directory, you can run:
Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.
The page will reload if you make edits.
You will also see any lint errors in the console.
Launches the test runner in the interactive watch mode.
See the section about running tests for more information.
Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Your app is ready to be deployed!
See the section about deployment for more information.
Note: this is a one-way operation. Once you eject, you can’t go back!
If you aren’t satisfied with the build tool and configuration choices, you can eject at any time. This command will remove the single build dependency from your project.
Instead, it will copy all the configuration files and the transitive dependencies (Webpack, Babel, ESLint, etc) right into your project so you have full control over them. All of the commands except eject will still work, but they will point to the copied scripts so you can tweak them. At this point you’re on your own.
You don’t have to ever use eject. The curated feature set is suitable for small and middle deployments, and you shouldn’t feel obligated to use this feature. However we understand that this tool wouldn’t be useful if you couldn’t customize it when you are ready for it.
Deploy code to Github Pages. Will appear here: https://rbitting.github.io/arc-accessibility-dashboard/
You can learn more in the Create React App documentation.
To learn React, check out the React documentation.
This section has moved here: https://facebook.github.io/create-react-app/docs/code-splitting
This section has moved here: https://facebook.github.io/create-react-app/docs/analyzing-the-bundle-size
This section has moved here: https://facebook.github.io/create-react-app/docs/making-a-progressive-web-app
This section has moved here: https://facebook.github.io/create-react-app/docs/advanced-configuration
This section has moved here: https://facebook.github.io/create-react-app/docs/deployment
This section has moved here: https://facebook.github.io/create-react-app/docs/troubleshooting#npm-run-build-fails-to-minify