diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 1f457785f..df080857b 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -8,3 +8,4 @@ I have verified that this pull request: * [ ] has no test errors (`npm run test`) * [ ] is from a uniquely-named feature branch and is up to date with the `develop` branch. * [ ] is descriptively named and links to an issue number, i.e. `Fixes #123` +* [ ] meets the standards outlined in the [accessibility guidelines](https://github.com/processing/p5.js-web-editor/blob/develop/contributor_docs/accessibility.md) diff --git a/contributor_docs/accessibility.md b/contributor_docs/accessibility.md index a4adbfbb2..8d234af07 100644 --- a/contributor_docs/accessibility.md +++ b/contributor_docs/accessibility.md @@ -4,6 +4,7 @@ Here is a guide on [how to use the accessible editor](https://gist.github.com/Ma The code for the p5.js web editor adheres to web accessibility standards. The following guidelines will help to ensure that accessibility continues to be a priority as development continues. +## Screen Reader and Keyboard Access **Code Structure** * Screen Readers are an assistive technology for vision loss that helps users to navigate a web page. They are able to prioritize content based on the semantic meaning of HTML tags. Therefore, it is important to use specific tags, such as `nav`, `ul`, `li`, `section`, and so on. `div` is the least screen reader-friendly tag. For example, [here is the semantic meaning of the `body` tag](http://html5doctor.com/element-index/#body) @@ -17,4 +18,44 @@ The code for the p5.js web editor adheres to web accessibility standards. The fo * All ``s need to have a `summary` attribute. This will ensure user is given context to what the table is. [code example](https://github.com/processing/p5.js-web-editor/blob/edae248eede21d7ad7702945929efbcdfeb4d9ea/client/modules/IDE/components/SketchList.jsx#L491) * `ul`s and `nav`s menus need to include a title. [code example](https://github.com/processing/p5.js-web-editor/blob/edae248eede21d7ad7702945929efbcdfeb4d9ea/client/components/Nav.jsx#L281) -For more information on accessibility see the [teach access tutorial](https://teachaccess.github.io/tutorial/) + +## Color Blind and Low-Vision Accessibility + +To make the editor accessible to color blind and low-vision users, it is important to adhere to the [WCAG 2.2 accessibility guidelines](https://www.w3.org/TR/WCAG22/) relating to adequate color contrast and the use of color to convey information. + +**Contrast** + +* The [WCAG 2.2 accessibility guidelines](https://www.w3.org/TR/WCAG22/) include guidelines [1.4.3: Perceivable - Contrast (minimum)](https://www.w3.org/TR/WCAG22/#contrast-minimum) and [1.4.11: Perceivable - Non-text Contrast](https://www.w3.org/TR/WCAG22/#non-text-contrast). The guideline for contrast is to ensure that color blind and low-vision users are able to visually distinguish elements that are different colors from one another. + +* These guidelines specify the AA standard of contrast ratios between the foreground and background of different types of text, images, and UI components. + + * Small text (above 14pt and below 18pt and not bold) must have a contrast ratio of at least 4.5:1 + * [Large text](https://www.w3.org/TR/WCAG22/#dfn-large-scale) (above 18 pt regular/14 pt bold or roughly 1.2-1.5em) must have a contrast ratio of at least 3:1 + * UI components must have a contrast ratio of at least 3:1 against all adjacent colors + * The color marking the state of UI components (ie active vs inactive) must have a contrast ratio of at least 3:1 relative to each other + * Graphics that are required for understanding content must have a contrast ratio of at least 3:1 against all adjacent colors + * Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement. + * Text that is part of a logo or brand name has no contrast requirement. + +* The [Colour Contrast Analyser](https://www.tpgi.com/color-contrast-checker/) tool by TPGi is a downloadable app that allows you to check color contrast and see if it complies with requirements for small text, large text, and GUI elements. + +* It is recommended that you adhere to the codelens color palettes (light, dark, and contrast) when contributing to the p5 editor, which define different colors for different parts of the GUI. These colors can be found in client/styles/components/abstracts/variables.scss. Many components come with color defaults that use theme-wide color styles. Some color combinations within the palettes meet foreground/background contrast requirements and others do not, so it is important to check them. + +**Use of Color** +* The [WCAG 2.2 accessibility guidelines](https://www.w3.org/TR/WCAG22/) include [guideline 1.4.1 - perceivable: use of color](https://www.w3.org/TR/WCAG22/#use-of-color). This guideline states that “Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.” +* Essentially, information that the user needs to be aware of such as the presence of links, the state of buttons, and the presence of errors should not be communicated through color (hue) differences alone. Additionally, the user must not be expected to correctly identify a specific color to use the site (e.g saying “errors are marked in red”). +* This does not mean color cannot be used to convey information - that is great design practice! However, that information should also be conveyed in an additional way. +* Ways to convey information include: + * [using text labels in addition to color](https://www.w3.org/WAI/WCAG22/Techniques/general/G14) + * [using additional non-color styling cues](https://www.w3.org/WAI/WCAG22/Techniques/general/G182) such as underlining or bolding text to differentiate links from surrounding text + * [using different fill patterns](https://www.w3.org/WAI/WCAG22/Techniques/general/G111) to differentiate GUI elements + *[using appropriate contrast](https://www.w3.org/WAI/WCAG22/Techniques/general/G183) (meaning differences in lightness/darkness instead of just hue) between differently colored elements. +* Using styling that is completely unrelated to color is often the most straightforward way to meet this guideline, compared to color contrast which requires more attention to detail on a per-component basis to implement and maintain. + +## Accessible web design resources +* For more information on accessibility see the [teach access tutorial](https://teachaccess.github.io/tutorial/) +* [WCAG 2.2 Guidelines](https://www.w3.org/WAI/WCAG22/quickref) +* [Checklist - The A11Y Project](https://www.a11yproject.com/checklist/) - a basic accessibility checklist based on the WCAG 2.2 guidelines +* [Resources - The A11Y Project](https://www.a11yproject.com/resources/) - resource library including articles, tools, and classes on accessible web design. +* [Deque University](https://dequeuniversity.com/) - classes and articles on accessible design +* [Color accessibility beyond a pass/fail by Lauren Jong](https://medium.com/san-francisco-digital-services/color-accessibility-beyond-a-pass-fail-2ea19be4b3c1) - a more nuanced case study on designing for accessibility with regard to color