` – Equivalent to “directing the gaze” of the screen reader user. Should contain only the primary content of the page.
35 | - `
` tag. If you are on a Mac, turn on VoiceOver with Cmd + F5 and then press Ctrl + Opt + Cmd + h to jump to a heading.
12 |
13 | import { Editor } from "../_util/Editor.mdx"
14 |
15 |
16 | {`
17 | A real heading
18 |
`}
19 |
20 |
21 | ## Exercise: Unsemantic heading
22 |
23 | The heading below is a fake heading made to look like a heading with an unsemantic ``. Change the `` below to use an `` tag. Now verify your semantic heading using the Verify button as well as with VoiceOver.
24 |
25 | {
27 | const h3s = exercise.querySelectorAll("h3")
28 | if (h3s.length !== 1) {
29 | return "It doesn't look like you converted the div to a real heading."
30 | }
31 | }}
32 | >{`A fake heading`}
33 |
--------------------------------------------------------------------------------
/docs/design/site-copy.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Site copy
3 | sidebar_label: 3.5. Site copy
4 | id: site-copy
5 | ---
6 |
7 | The content you write for your website or application matters a great deal for
8 | its usability and accessibility. The Web Content Accessibility Guidelines
9 | recommends that you use a reading ability equivalent of a [lower secondary
10 | education level](http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-supplements).
11 | That's a good, general rule of thumb to go by. Here are a few more:
12 |
13 | - Avoid using directional language like “below” and “left/right.” These require
14 | that you can see the visual layout of the page.
15 | - Use alt-text for images. Alt-text describes the contents of an image to
16 | someone who is visually impaired and using a screen reader. If your designs
17 | include images that you've created (not user-generated images), you need to
18 | provide alt-text in your front end layer.
19 | - Provide explanatory and context-specific text where possible. Explanatory text
20 | consists of short text strings that describe an interface element’s function
21 | (ex: if you have a search button that looks like a magnifying glass, you
22 | might consider adding an on-hover tooltip of "Search").
23 |
24 | Take note that if your website or application includes other text artifacts like
25 | PDFs, you may need to provide unique accessibility support for those media.
26 |
--------------------------------------------------------------------------------
/docs/design/color-meaning.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Color meaning
3 | sidebar_label: 3.3. Color meaning
4 | id: color-meaning
5 | ---
6 |
7 | Color blindness is the inability or decreased ability to see color or perceive
8 | color differences. [Approximately 4.5% of the world's population](https://nei.nih.gov/health/color_blindness/facts_about) are color blind to some degree. In order to ensure that someone with color blindness can
9 | successfully use your product, you cannot rely completely on color alone to
10 | communicate information. By extension, using colors or patterns alone to
11 | indicate something will not be accessible to blind users. In instances where
12 | you are using color as an indicator (for instance, green for something active
13 | and grey for something inactive), include a text equivalent description for the
14 | state.
15 |
16 | Here's an example where providing a very simple texture to a bar chart will aid in readability and understanding for someone with decreased color perception.
17 |
18 |
19 | 
20 | Figure A: Chart without Texture
21 |
22 |
23 |
24 | 
25 | Figure B: Chart with Texture
26 |
27 |
--------------------------------------------------------------------------------
/website/package.json:
--------------------------------------------------------------------------------
1 | {
2 | "scripts": {
3 | "examples": "docusaurus-examples",
4 | "start": "docusaurus start",
5 | "build": "docusaurus build",
6 | "publish-gh-pages": "docusaurus-publish",
7 | "write-translations": "docusaurus-write-translations",
8 | "version": "docusaurus-version",
9 | "rename-version": "docusaurus-rename-version",
10 | "swizzle": "docusaurus swizzle",
11 | "deploy": "docusaurus deploy",
12 | "docusaurus": "docusaurus",
13 | "lint": "npx eslint --fix ."
14 | },
15 | "devDependencies": {
16 | "eslint": "^7.2.0",
17 | "eslint-config-airbnb": "18.2.1",
18 | "eslint-config-prettier": "^8.3.0",
19 | "eslint-plugin-import": "^2.22.1",
20 | "eslint-plugin-jsx-a11y": "^6.4.1",
21 | "eslint-plugin-prettier": "^4.0.0",
22 | "eslint-plugin-react": "^7.21.5",
23 | "eslint-plugin-react-hooks": "^1.7.0",
24 | "prettier": "2.4.1"
25 | },
26 | "dependencies": {
27 | "@codemirror/basic-setup": "^0.19.0",
28 | "@codemirror/lang-html": "^0.19.3",
29 | "@codemirror/state": "^0.19.5",
30 | "@codemirror/view": "^0.19.16",
31 | "@docusaurus/core": "^2.0.0-beta.15",
32 | "@docusaurus/preset-classic": "^2.0.0-beta.15",
33 | "@docusaurus/theme-live-codeblock": "^2.0.0-beta.15",
34 | "clsx": "^1.1.1",
35 | "html-react-parser": "^1.4.0",
36 | "react": "^17.0.1",
37 | "react-dom": "^17.0.1"
38 | }
39 | }
40 |
--------------------------------------------------------------------------------
/docs/code/checklist.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Checklist
3 | sidebar_label: 2.12. Checklist
4 | id: checklist
5 | ---
6 |
7 | We've covered a bunch of ground related to accessible software development. One of the most important steps you can take is accounting for accessibility throughout the development process (not just at the end!). To aid in that process, use the following checklist as you develop your website or application:
8 |
9 | - [ ] Do all images have meaningful alternative text?
10 | - [ ] Is every focusable element operable using the keyboard alone?
11 | - [ ] Is there a consistent visible focus indicator when navigating using the keyboard?
12 | - [ ] Have all controls, frames, and page titles been labeled meaningfully and uniquely?
13 | - [ ] If custom controls/components have been implemented, have these been tested to assure that assistive technology recognizes name, role, state, and value (where applicable)?
14 | - [ ] Have custom controls/components been verified to work as expected using assistive technology, such as a screen reader?
15 | - [ ] Are error messages interpretable by assistive technology?
16 | - [ ] Do you have sufficient foreground and background color contrast?
17 | - [ ] Have captions been included with any audio or audio/visual media?
18 |
19 | There are also a number of free tools available for assessing the accessibility:
20 |
21 | - [WAVE by WebAIM for general website accessibility](http://wave.webaim.org/)
22 | - [Juicy Studio's Readability Test](http://juicystudio.com/services/readability.php)
23 | - [Vischeck's Color Blindness Checker](http://www.vischeck.com/)
24 |
--------------------------------------------------------------------------------
/docs/introduction/faq.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: FAQs
3 | sidebar_label: 1.2. FAQs
4 | id: faq
5 | ---
6 |
7 | Got questions about Teach Access and the Teach Access Tutorial? Fire away!
8 |
9 | **What is Teach Access?**
10 |
11 | Teach Access is a collective of leading tech companies, academic institutions and advocacy organizations working together to embed accessibility into higher education and learning experiences for students of technology.
12 |
13 | **What is the Teach Access Tutorial?**
14 |
15 | The Teach Access Tutorial is a hands-on tutorial that covers some best practices for writing accessible software and designing inclusive experiences.
16 |
17 | **What assistive technologies can I use with this tutorial?**
18 |
19 | The tutorial should work with most assistive technologies, but Apple's VoiceOver is the recommended screen reader for the training exercises.
20 |
21 | **Where can I find more information on accessibility?**
22 |
23 | Here are a few resources to get you started:
24 |
25 | - [Web Content Accessibility Guidelines](https://www.w3.org/WAI/intro/wcag)
26 | - [WebAIM](http://webaim.org)
27 |
28 | **What are some good, free, developer tools for accessibility?**
29 |
30 | - [WAVE by WebAIM for general website accessibility](http://wave.webaim.org/)
31 | - [Juicy Studio's Readability Test](http://juicystudio.com/services/readability.php)
32 | - [Vischeck's Color Blindness Checker](http://www.vischeck.com/)
33 |
34 | **Are there jobs in the field of accessibility?**
35 |
36 | Definitely, and the industry is growing. Explore opportunities on Twitter: [@a11yJobs](https://twitter.com/a11yjobs)
37 |
--------------------------------------------------------------------------------
/docs/design/checklist.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Checklist
3 | sidebar_label: 3.7. Checklist
4 | id: checklist
5 | ---
6 |
7 | We've covered a bunch of ground related to improving the accessibility of visual designs. One of the most important steps you can take to ensuring you create accessible experiences is accounting for accessibility at the start and throughout the design process. To that end, use the following checklist when you begin to formalize your visual designs for a website or application:
8 |
9 | - Do I have sufficient contrast between text and my background?
10 | - Do I have sufficient contrast between UI elements and my background?
11 |
12 | - Are there any places where I'm color or other visual means alone to indicate something (ie, no text equivalent)?
13 | - Is my written content simple and easy to understand?
14 | - Are there any cases where the screen is flashing or flickering?
15 | - Does every mouse interaction have a keyboard-only equivalent interaction?
16 | - Have captions been included with any audio or audio/visual presentation?
17 | - If any interaction involves a timed response or session timeout, is this communicated well?
18 |
19 | There are also a number of free tools available for assessing the accessibility:
20 |
21 | - [WAVE by WebAIM for general website accessibility](http://wave.webaim.org/)
22 | - [Juicy Studio's Readability Test](http://juicystudio.com/services/readability.php)
23 | - [Vischeck's Color Blindness Checker](http://www.vischeck.com/)
24 | - [Functional Accessibility Evaluator 2.2](https://fae.disability.illinois.edu)
25 | - [AInspector Sidebar for Firefox](http://ainspector.github.io)
26 | - [Pa11y](http://pa11y.org)
27 | - [Koa11y](https://open-indy.github.io/Koa11y)
28 |
--------------------------------------------------------------------------------
/docs/code/images.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Images
3 | sidebar_label: 2.3. Images
4 | id: images
5 | ---
6 |
7 | import { Editor } from "../_util/Editor.mdx"
8 |
9 | Screen readers interact with text on the screen. So, to convey the meaning of
10 | an image to screen reader users, we put an accessible text label in the HTML. If an image is decorative, we can hide it from screen reader users by giving it an empty label (`alt=""`). After completing the exercise below, you can learn a lot more about writing good alt text for images by checking out [WebAIM's resource on the
11 | topic](http://webaim.org/techniques/alttext/).
12 |
13 | ## Accessible inline image
14 |
15 | This is an image with an `alt` attribute. Turn on VoiceOver if you are on a Mac, tab
16 | to the Editor Output section, and use Ctrl + Opt + Right Arrow
17 | to navigate to these images. VoiceOver will announce the `alt` text. For the second image below, VoiceOver
18 | will not announce anything meaningful since there is no `alt` text.
19 |
20 |
21 | {`
`}
25 |
26 |
27 | ## Exercise: Inaccessible inline image
28 |
29 | This is an image without `alt` text. Turn on VoiceOver and listen to how it is read. Add an `alt` attribute "Teach Access logo" to this image to make it accessible and test it again with VoiceOver.
30 |
31 | {
33 | const images = Array.from(exercise.getElementsByTagName("img"))
34 | const missingAltTag = images.some((image) => !image.hasAttribute("alt"))
35 | if (missingAltTag) {
36 | return "It doesn't look like you added an alt to your image."
37 | }
38 | }}
39 | >
40 | {``}
43 |
44 |
--------------------------------------------------------------------------------
/website/docusaurus.config.js:
--------------------------------------------------------------------------------
1 | const config = {
2 | title: "Teach Access Tutorial",
3 | tagline: "Best practices for making accessible mobile and web apps",
4 | url: "https://teachaccess.github.io",
5 | baseUrl: "/tutorial/",
6 | organizationName: "teachaccess",
7 | projectName: "tutorial",
8 | deploymentBranch: "gh-pages",
9 | scripts: [
10 | "https://buttons.github.io/buttons.js",
11 | "/tutorial/js/scriptHelper.js",
12 | ],
13 | favicon: "img/logo-teach-access.svg",
14 | onBrokenLinks: "throw",
15 | onBrokenMarkdownLinks: "throw",
16 | trailingSlash: false,
17 | presets: [
18 | [
19 | "@docusaurus/preset-classic",
20 | {
21 | docs: {
22 | showLastUpdateAuthor: true,
23 | showLastUpdateTime: true,
24 | path: "../docs",
25 | sidebarPath: require.resolve("./sidebars.js"),
26 | routeBasePath: "/",
27 | },
28 | theme: {
29 | customCss: "../src/css/customTheme.css",
30 | },
31 | },
32 | ],
33 | ],
34 | plugins: ["@docusaurus/theme-live-codeblock"],
35 | themeConfig: {
36 | navbar: {
37 | logo: {
38 | src: "img/logo-teach-access.svg",
39 | srcDark: "img/logo-teach-access-dark.svg",
40 | alt: "Teach Access",
41 | },
42 | items: [
43 | {
44 | to: "/",
45 | label: "Tutorial",
46 | position: "left",
47 | },
48 | {
49 | to: "/help",
50 | label: "Help",
51 | position: "left",
52 | },
53 | ],
54 | },
55 | image: "img/undraw_online.svg",
56 | footer: {
57 | links: [],
58 | copyright: "Copyright © 2022 Teach Access",
59 | logo: {
60 | src: "img/logo-teach-access.svg",
61 | srcDark: "img/logo-teach-access-dark.svg",
62 | alt: "Teach Access",
63 | },
64 | },
65 | },
66 | };
67 |
68 | module.exports = config;
69 |
--------------------------------------------------------------------------------
/docs/code/aria-introduction.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: ARIA Introduction
3 | sidebar_label: 2.10. ARIA Introduction
4 | id: aria-introduction
5 | ---
6 |
7 | Websites were simple, accessible documents in the early days of the Internet. But accessibility was lost when websites became applications. [Accessible Rich Internet Aplications (ARIA)](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) extends HTML to create accessible web applications.
8 |
9 | ARIA is a set of HTML attributes for developers to control the information surfaced by assistive technology. ARIA can define an element's label, state, properties, and role.
10 |
11 | ARIA is a powerful tool and must be used with care. The [first rule of ARIA](https://www.w3.org/TR/using-aria/#rule1) is to not use ARIA. Use semantic HTML and augment with ARIA. However, we often need to use ARIA to extend HTML or fix inaccessible code. Understanding ARIA is critical for today's web developers.
12 |
13 | ARIA does not make your application accessible. It makes it understandable. You can't put role="button" on a div and expect it to work with a keyboard and screen reader. Adding role="button" simply tells assistive technology to expect the div is actually a button. You would still need to make the div focusable and listen for onkeypress of enter and spacebar. Which is why it's always better to start with a semantic button.
14 |
15 | ### Commonly used ARIA attributes
16 |
17 | - [Roles](https://www.w3.org/TR/wai-aria-1.1/#roles): button, img, link
18 | - [Properties](https://www.w3.org/TR/wai-aria-1.1/#global_states): aria-label, aria-live, aria-haspopup
19 | - [States](https://www.w3.org/TR/wai-aria-1.1/#global_states): aria-required, aria-selected, aria-expanded
20 | - [Landmarks](https://www.w3.org/TR/wai-aria-1.1/#landmark_roles): main, banner, search, region
21 | - [Complex roles](https://www.w3.org/TR/wai-aria-1.1/#widget_roles): alert, tablist, table, toolbar
22 |
23 | You will find ARIA examples within the Tutorial pages.
24 |
--------------------------------------------------------------------------------
/docs/design/text-size.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Text
3 | sidebar_label: 3.4. Text
4 | id: text
5 | ---
6 |
7 | People with low vision use browser zoom tools and assistive technology such as
8 | [ZoomText](http://www.aisquared.com/products/zoomtext/) to increase the size of
9 | content on the screen. This exercise shows you the difference between zooming
10 | all the content versus zooming just the text on the page.
11 |
12 | ## Text size
13 |
14 | For people with low vision, it is important to support the ability to increase
15 | text size without text overlapping or getting truncated. To test, use your browser's
16 | built-in zoom or text-resize feature to zoom and make sure text is still readable.
17 | If you are building for the mobile web, please don't disable pinch and zoom.
18 |
19 | [WCAG guidelines recommend allowing zooming up to 200% without loss of
20 | content.](http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-scale)
21 |
22 | [More on fonts and accessibility in the WebAIM
23 | site.](http://webaim.org/techniques/fonts/#font_size)
24 |
25 | For the exercise below, you will need a browser like Safari that allows you to
26 | increase just the text size instead of zooming in the whole page. On Safari,
27 | go to View and Zoom Text Only and then select Zoom In from the same menu. You
28 | will notice that the words bleed outside the box below. Try fixing this example
29 | by specifying the width and height as relative units, such as ems. Set the height
30 | to 3em and width to 10em and verify your answers.
31 |
32 | import { Editor } from "../_util/Editor.mdx"
33 |
34 | {
36 | const container = exercise.querySelector("#container")
37 | const isValid =
38 | container.style.height === "3em" && container.style.width === "10em"
39 | if (!isValid) {
40 | return "It doesn't seem like the height and width are set to the right ems"
41 | }
42 | }}
43 | >
44 | {`
48 | Lorem ipsum dolor sit amet
49 | `}
50 |
51 |
--------------------------------------------------------------------------------
/docs/design/photos.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Photos
3 | sidebar_label: 3.6. Photos
4 | id: photos
5 | ---
6 |
7 | While alt-text can make a static photo or graphic accessible to screen reader users, when an image is dynamic (e.g., animated GIF or video) and contains audio, additional support is required for users who are blind or deaf.
8 |
9 |
10 | 
12 |
13 |
14 | When providing video, via either an embedded or standalone video player, the controls of that player need to be operable by a keyboard-only user (i.e., without a mouse). Controls such as play, pause, fast forward, rewind and scrub bars and closed caption buttons all need to be labeled properly and available to a screen reader user in the same way any web page is made accessible.
15 |
16 | "Audio description" (also known as "video description") provides an added narrative track that describes key visual elements of a animation or video or movie. Timed to be heard during pauses in dialog, descriptions can be recorded and synchronized with the video or made available as text to be read by a screen reader. With HTML5 video players and the video and track elements, audio descriptions can even be heard while a video is automatically paused. For more on how to deliver descriptions, see the following resources:
17 |
18 | -
20 | -
26 |
--------------------------------------------------------------------------------
/docs/introduction/using-this-tutorial.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Using this tutorial
3 | sidebar_label: 1.1. Using this tutorial
4 | id: using-this-tutorial
5 | slug: /
6 | ---
7 |
8 | Welcome to the Teach Access Tutorial! This resource is part of the Teach Access Initiative, and provides best practices for making accessible mobile and web apps. This tutorial currently provides basic training for developers and designers, with more disciplines to come! If you are new to accessibility, you've come to the right place - the following material will help you get a solid footing on accessibility via hands-on exercises and useful reference guides. Follow the instructions below for using and interacting with the tutorial.
9 |
10 | 1. You can use the left and right arrow keys to navigate through the slides.
11 |
12 | 1. Each slide has some core concepts, code samples, and one or more exercises. After you complete an exercise,
13 | use the verify button to check whether your solution is correct.
14 |
15 | 1. You can also verify the code sample output using VoiceOver - Apple's built-in screen reader (other screen readers work too). Here are some instructions for navigating with VoiceOver:
16 |
17 | - cmd + F5 turns VoiceOver on/off
18 | - tab navigates to an interactive element
19 | - ctrl + opt + right arrow (repeatedly)
20 | navigates to the next element
21 | - ctrl + opt + cmd + h
22 | (repeatedly) navigates by headings
23 |
24 | **Please note:** the majority of people who use a screen reader [prefer JAWS or NVDA on a Windows machine](https://webaim.org/projects/screenreadersurvey9/#primary). WebAim has great articles about testing your code with [NVDA](https://webaim.org/articles/nvda/) and [JAWS.](https://webaim.org/articles/jaws/)
25 |
26 | 1. When verifying with VoiceOver, use Chrome on a Mac for the best experience. However, the "Verify" button provided after each exercise will work with any browser/OS combination.
27 |
28 | 1. ARIA stands for Accessible Rich Internet Applications, a W3C standard for
29 | building accessible user interfaces on the web.
30 |
31 | Happy learning!
32 |
--------------------------------------------------------------------------------
/docs/_util/Editor.mdx:
--------------------------------------------------------------------------------
1 | import { EditorView, basicSetup } from "@codemirror/basic-setup";
2 | import { EditorState } from "@codemirror/state";
3 | import { html } from "@codemirror/lang-html";
4 | import parse from "html-react-parser";
5 | import { VerifyButton } from "../_util/VerifyButton.mdx";
6 |
7 | export const Editor = ({ checkExercise, children: initialHtml = "" }) => {
8 | const [editorId] = React.useState(Math.round(Math.random() * 100000));
9 | const [view, setView] = React.useState();
10 | const [output, setOutput] = React.useState(initialHtml);
11 | const resultRef = React.useRef();
12 | React.useEffect(() => {
13 | const editorView = new EditorView({
14 | state: EditorState.create({
15 | doc: initialHtml,
16 | extensions: [
17 | basicSetup,
18 | html(),
19 | EditorView.updateListener.of((v) => {
20 | if (v.docChanged) {
21 | setOutput(v.state.doc.toString());
22 | }
23 | }),
24 | ],
25 | }),
26 | parent: document.querySelector(`#editor-${editorId}`),
27 | });
28 | setView(editorView);
29 | }, []);
30 | const renderEditor = (
31 |
32 | Live editor
33 |
37 |
38 | );
39 | const renderResult = (
40 |
41 | Result
42 |
48 |
49 | );
50 | const renderVerifyButton = checkExercise && (
51 | checkExercise(resultRef.current)} />
52 | );
53 | return (
54 | <>
55 |
56 | {renderEditor}
57 | {renderResult}
58 |
59 | {renderVerifyButton}
60 |
61 | );
62 | };
63 |
--------------------------------------------------------------------------------
/docs/code/keyboard-navigation.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Keyboard navigation
3 | sidebar_label: 2.4. Keyboard navigation
4 | id: keyboard-navigation
5 | ---
6 |
7 | Make all interactive elements work with a keyboard. For example, make sure a
8 | button that you activate with a click is also in the keyboard tab sequence and that pressing enter or space
9 | activates it. Set the `tabindex` attribute to `0` to include an element in the
10 | browser's keyboard tab sequence. If you want an element out of sequence, set
11 | its `tabindex` to `-1` and use JavaScript to control its focus and tab
12 | sequence, and related keyboard events. We do not recommend using `tabindex`
13 | values greater than `0` even though browsers support them. Note that HTML links
14 | and input elements have an implied `tabindex` of `0`.
15 |
16 | ## Semantic button
17 |
18 | The button below uses a semantic `button` tag and is correctly announced by
19 | screen readers. If you are on a Mac, turn on VoiceOver and tab to the
20 | button. You will hear the name of the element and the element type announced
21 | by VoiceOver.
22 |
23 |
24 | {``}
27 |
28 |
29 | ## Exercise: Unsemantic button
30 |
31 | The button below is constructed using an unsemantic `div`. The easiest way to
32 | make this semantic is to use a real `button` or `input` tag. Here is another way. In the
33 | example below, add
34 |
35 | 1. `role='button'`
36 | 1. `tabindex='0'`
37 |
38 | Verify with VoiceOver that you can tab to the button and hear the button name and the fact
39 | that it is a button element. Note that you would need to add an `onkeypress` or `onkeydown` handler to the button so you can tab to the button and press enter to activate it using just the keyboard.
40 |
41 | import { Editor } from "../_util/Editor.mdx"
42 |
43 | {
45 | const [button] = exercise.getElementsByClassName("customButton")
46 | const isValid =
47 | button.hasAttribute("tabindex") &&
48 | button.getAttribute("tabindex") === "0" &&
49 | button.getAttribute("role") === "button"
50 | if (!isValid) {
51 | return "It doesn't look like your custom button is accessible yet."
52 | }
53 | }}
54 | >
55 | {`
56 | Submit
57 | `}
58 |
59 |
--------------------------------------------------------------------------------
/docs/code/landmarks.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Landmarks
3 | sidebar_label: 2.11. Landmarks
4 | id: landmarks
5 | ---
6 |
7 | For this exercise, we will focus on one small part of WAI-ARIA called landmark regions. Landmark regions help screen reader users do what others do when they glance at a page, i.e., see its different parts from a bird’s-eye view. They also make it easy to move the screen reader’s reading cursor to different locations on the page.
8 |
9 | 1. Turn on VoiceOver.
10 | 2. Press `Ctrl` + `Opt` + `u`.
11 | 3. Press right arrow until you hear “Landmarks”.
12 | 4. Press down arrow to read the landmark list.
13 | 5. Press enter to move the VoiceOver reading cursor to the beginning of one of the landmark regions.
14 |
15 | ## Exercise: ARIA landmarks
16 |
17 | import { Editor } from "../_util/Editor.mdx"
18 |
19 | {
21 | const { value } = exercise.getElementById("landmarks")
22 | const isValid = value === "4" || value === "four"
23 | if (!isValid) {
24 | return "That is not the right number of landmarks on the page!"
25 | }
26 | }}
27 | >
28 | {`How many landmarks did you find on the page?
29 | `}
30 |
31 |
32 | There are several types of landmark roles. Some of them are:
33 |
34 | - ``, `
17 | A real heading 18 |
`} 19 |` below to use an `` tag. Now verify your semantic heading using the Verify button as well as with VoiceOver.
24 |
25 |
` tag. Now verify your semantic heading using the Verify button as well as with VoiceOver.
24 |
25 | {
27 | const h3s = exercise.querySelectorAll("h3")
28 | if (h3s.length !== 1) {
29 | return "It doesn't look like you converted the div to a real heading."
30 | }
31 | }}
32 | >{`A fake heading`}
33 |
--------------------------------------------------------------------------------
/docs/design/site-copy.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Site copy
3 | sidebar_label: 3.5. Site copy
4 | id: site-copy
5 | ---
6 |
7 | The content you write for your website or application matters a great deal for
8 | its usability and accessibility. The Web Content Accessibility Guidelines
9 | recommends that you use a reading ability equivalent of a [lower secondary
10 | education level](http://www.w3.org/WAI/WCAG20/quickref/#qr-meaning-supplements).
11 | That's a good, general rule of thumb to go by. Here are a few more:
12 |
13 | - Avoid using directional language like “below” and “left/right.” These require
14 | that you can see the visual layout of the page.
15 | - Use alt-text for images. Alt-text describes the contents of an image to
16 | someone who is visually impaired and using a screen reader. If your designs
17 | include images that you've created (not user-generated images), you need to
18 | provide alt-text in your front end layer.
19 | - Provide explanatory and context-specific text where possible. Explanatory text
20 | consists of short text strings that describe an interface element’s function
21 | (ex: if you have a search button that looks like a magnifying glass, you
22 | might consider adding an on-hover tooltip of "Search").
23 |
24 | Take note that if your website or application includes other text artifacts like
25 | PDFs, you may need to provide unique accessibility support for those media.
26 |
--------------------------------------------------------------------------------
/docs/design/color-meaning.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Color meaning
3 | sidebar_label: 3.3. Color meaning
4 | id: color-meaning
5 | ---
6 |
7 | Color blindness is the inability or decreased ability to see color or perceive
8 | color differences. [Approximately 4.5% of the world's population](https://nei.nih.gov/health/color_blindness/facts_about) are color blind to some degree. In order to ensure that someone with color blindness can
9 | successfully use your product, you cannot rely completely on color alone to
10 | communicate information. By extension, using colors or patterns alone to
11 | indicate something will not be accessible to blind users. In instances where
12 | you are using color as an indicator (for instance, green for something active
13 | and grey for something inactive), include a text equivalent description for the
14 | state.
15 |
16 | Here's an example where providing a very simple texture to a bar chart will aid in readability and understanding for someone with decreased color perception.
17 |
18 |
19 |
20 | Figure A: Chart without Texture
21 |
22 |
23 |
24 |
25 | Figure B: Chart with Texture
26 |
27 |
--------------------------------------------------------------------------------
/website/package.json:
--------------------------------------------------------------------------------
1 | {
2 | "scripts": {
3 | "examples": "docusaurus-examples",
4 | "start": "docusaurus start",
5 | "build": "docusaurus build",
6 | "publish-gh-pages": "docusaurus-publish",
7 | "write-translations": "docusaurus-write-translations",
8 | "version": "docusaurus-version",
9 | "rename-version": "docusaurus-rename-version",
10 | "swizzle": "docusaurus swizzle",
11 | "deploy": "docusaurus deploy",
12 | "docusaurus": "docusaurus",
13 | "lint": "npx eslint --fix ."
14 | },
15 | "devDependencies": {
16 | "eslint": "^7.2.0",
17 | "eslint-config-airbnb": "18.2.1",
18 | "eslint-config-prettier": "^8.3.0",
19 | "eslint-plugin-import": "^2.22.1",
20 | "eslint-plugin-jsx-a11y": "^6.4.1",
21 | "eslint-plugin-prettier": "^4.0.0",
22 | "eslint-plugin-react": "^7.21.5",
23 | "eslint-plugin-react-hooks": "^1.7.0",
24 | "prettier": "2.4.1"
25 | },
26 | "dependencies": {
27 | "@codemirror/basic-setup": "^0.19.0",
28 | "@codemirror/lang-html": "^0.19.3",
29 | "@codemirror/state": "^0.19.5",
30 | "@codemirror/view": "^0.19.16",
31 | "@docusaurus/core": "^2.0.0-beta.15",
32 | "@docusaurus/preset-classic": "^2.0.0-beta.15",
33 | "@docusaurus/theme-live-codeblock": "^2.0.0-beta.15",
34 | "clsx": "^1.1.1",
35 | "html-react-parser": "^1.4.0",
36 | "react": "^17.0.1",
37 | "react-dom": "^17.0.1"
38 | }
39 | }
40 |
--------------------------------------------------------------------------------
/docs/code/checklist.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Checklist
3 | sidebar_label: 2.12. Checklist
4 | id: checklist
5 | ---
6 |
7 | We've covered a bunch of ground related to accessible software development. One of the most important steps you can take is accounting for accessibility throughout the development process (not just at the end!). To aid in that process, use the following checklist as you develop your website or application:
8 |
9 | - [ ] Do all images have meaningful alternative text?
10 | - [ ] Is every focusable element operable using the keyboard alone?
11 | - [ ] Is there a consistent visible focus indicator when navigating using the keyboard?
12 | - [ ] Have all controls, frames, and page titles been labeled meaningfully and uniquely?
13 | - [ ] If custom controls/components have been implemented, have these been tested to assure that assistive technology recognizes name, role, state, and value (where applicable)?
14 | - [ ] Have custom controls/components been verified to work as expected using assistive technology, such as a screen reader?
15 | - [ ] Are error messages interpretable by assistive technology?
16 | - [ ] Do you have sufficient foreground and background color contrast?
17 | - [ ] Have captions been included with any audio or audio/visual media?
18 |
19 | There are also a number of free tools available for assessing the accessibility:
20 |
21 | - [WAVE by WebAIM for general website accessibility](http://wave.webaim.org/)
22 | - [Juicy Studio's Readability Test](http://juicystudio.com/services/readability.php)
23 | - [Vischeck's Color Blindness Checker](http://www.vischeck.com/)
24 |
--------------------------------------------------------------------------------
/docs/introduction/faq.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: FAQs
3 | sidebar_label: 1.2. FAQs
4 | id: faq
5 | ---
6 |
7 | Got questions about Teach Access and the Teach Access Tutorial? Fire away!
8 |
9 | **What is Teach Access?**
10 |
11 | Teach Access is a collective of leading tech companies, academic institutions and advocacy organizations working together to embed accessibility into higher education and learning experiences for students of technology.
12 |
13 | **What is the Teach Access Tutorial?**
14 |
15 | The Teach Access Tutorial is a hands-on tutorial that covers some best practices for writing accessible software and designing inclusive experiences.
16 |
17 | **What assistive technologies can I use with this tutorial?**
18 |
19 | The tutorial should work with most assistive technologies, but Apple's VoiceOver is the recommended screen reader for the training exercises.
20 |
21 | **Where can I find more information on accessibility?**
22 |
23 | Here are a few resources to get you started:
24 |
25 | - [Web Content Accessibility Guidelines](https://www.w3.org/WAI/intro/wcag)
26 | - [WebAIM](http://webaim.org)
27 |
28 | **What are some good, free, developer tools for accessibility?**
29 |
30 | - [WAVE by WebAIM for general website accessibility](http://wave.webaim.org/)
31 | - [Juicy Studio's Readability Test](http://juicystudio.com/services/readability.php)
32 | - [Vischeck's Color Blindness Checker](http://www.vischeck.com/)
33 |
34 | **Are there jobs in the field of accessibility?**
35 |
36 | Definitely, and the industry is growing. Explore opportunities on Twitter: [@a11yJobs](https://twitter.com/a11yjobs)
37 |
--------------------------------------------------------------------------------
/docs/design/checklist.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Checklist
3 | sidebar_label: 3.7. Checklist
4 | id: checklist
5 | ---
6 |
7 | We've covered a bunch of ground related to improving the accessibility of visual designs. One of the most important steps you can take to ensuring you create accessible experiences is accounting for accessibility at the start and throughout the design process. To that end, use the following checklist when you begin to formalize your visual designs for a website or application:
8 |
9 | - Do I have sufficient contrast between text and my background?
10 | - Do I have sufficient contrast between UI elements and my background?
11 |
12 | - Are there any places where I'm color or other visual means alone to indicate something (ie, no text equivalent)?
13 | - Is my written content simple and easy to understand?
14 | - Are there any cases where the screen is flashing or flickering?
15 | - Does every mouse interaction have a keyboard-only equivalent interaction?
16 | - Have captions been included with any audio or audio/visual presentation?
17 | - If any interaction involves a timed response or session timeout, is this communicated well?
18 |
19 | There are also a number of free tools available for assessing the accessibility:
20 |
21 | - [WAVE by WebAIM for general website accessibility](http://wave.webaim.org/)
22 | - [Juicy Studio's Readability Test](http://juicystudio.com/services/readability.php)
23 | - [Vischeck's Color Blindness Checker](http://www.vischeck.com/)
24 | - [Functional Accessibility Evaluator 2.2](https://fae.disability.illinois.edu)
25 | - [AInspector Sidebar for Firefox](http://ainspector.github.io)
26 | - [Pa11y](http://pa11y.org)
27 | - [Koa11y](https://open-indy.github.io/Koa11y)
28 |
--------------------------------------------------------------------------------
/docs/code/images.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Images
3 | sidebar_label: 2.3. Images
4 | id: images
5 | ---
6 |
7 | import { Editor } from "../_util/Editor.mdx"
8 |
9 | Screen readers interact with text on the screen. So, to convey the meaning of
10 | an image to screen reader users, we put an accessible text label in the HTML. If an image is decorative, we can hide it from screen reader users by giving it an empty label (`alt=""`). After completing the exercise below, you can learn a lot more about writing good alt text for images by checking out [WebAIM's resource on the
11 | topic](http://webaim.org/techniques/alttext/).
12 |
13 | ## Accessible inline image
14 |
15 | This is an image with an `alt` attribute. Turn on VoiceOver if you are on a Mac, tab
16 | to the Editor Output section, and use Ctrl + Opt + Right Arrow
17 | to navigate to these images. VoiceOver will announce the `alt` text. For the second image below, VoiceOver
18 | will not announce anything meaningful since there is no `alt` text.
19 |
20 |
21 | {``}
25 |
26 |
27 | ## Exercise: Inaccessible inline image
28 |
29 | This is an image without `alt` text. Turn on VoiceOver and listen to how it is read. Add an `alt` attribute "Teach Access logo" to this image to make it accessible and test it again with VoiceOver.
30 |
31 | {
33 | const images = Array.from(exercise.getElementsByTagName("img"))
34 | const missingAltTag = images.some((image) => !image.hasAttribute("alt"))
35 | if (missingAltTag) {
36 | return "It doesn't look like you added an alt to your image."
37 | }
38 | }}
39 | >
40 | {``}
43 |
44 |
--------------------------------------------------------------------------------
/website/docusaurus.config.js:
--------------------------------------------------------------------------------
1 | const config = {
2 | title: "Teach Access Tutorial",
3 | tagline: "Best practices for making accessible mobile and web apps",
4 | url: "https://teachaccess.github.io",
5 | baseUrl: "/tutorial/",
6 | organizationName: "teachaccess",
7 | projectName: "tutorial",
8 | deploymentBranch: "gh-pages",
9 | scripts: [
10 | "https://buttons.github.io/buttons.js",
11 | "/tutorial/js/scriptHelper.js",
12 | ],
13 | favicon: "img/logo-teach-access.svg",
14 | onBrokenLinks: "throw",
15 | onBrokenMarkdownLinks: "throw",
16 | trailingSlash: false,
17 | presets: [
18 | [
19 | "@docusaurus/preset-classic",
20 | {
21 | docs: {
22 | showLastUpdateAuthor: true,
23 | showLastUpdateTime: true,
24 | path: "../docs",
25 | sidebarPath: require.resolve("./sidebars.js"),
26 | routeBasePath: "/",
27 | },
28 | theme: {
29 | customCss: "../src/css/customTheme.css",
30 | },
31 | },
32 | ],
33 | ],
34 | plugins: ["@docusaurus/theme-live-codeblock"],
35 | themeConfig: {
36 | navbar: {
37 | logo: {
38 | src: "img/logo-teach-access.svg",
39 | srcDark: "img/logo-teach-access-dark.svg",
40 | alt: "Teach Access",
41 | },
42 | items: [
43 | {
44 | to: "/",
45 | label: "Tutorial",
46 | position: "left",
47 | },
48 | {
49 | to: "/help",
50 | label: "Help",
51 | position: "left",
52 | },
53 | ],
54 | },
55 | image: "img/undraw_online.svg",
56 | footer: {
57 | links: [],
58 | copyright: "Copyright © 2022 Teach Access",
59 | logo: {
60 | src: "img/logo-teach-access.svg",
61 | srcDark: "img/logo-teach-access-dark.svg",
62 | alt: "Teach Access",
63 | },
64 | },
65 | },
66 | };
67 |
68 | module.exports = config;
69 |
--------------------------------------------------------------------------------
/docs/code/aria-introduction.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: ARIA Introduction
3 | sidebar_label: 2.10. ARIA Introduction
4 | id: aria-introduction
5 | ---
6 |
7 | Websites were simple, accessible documents in the early days of the Internet. But accessibility was lost when websites became applications. [Accessible Rich Internet Aplications (ARIA)](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) extends HTML to create accessible web applications.
8 |
9 | ARIA is a set of HTML attributes for developers to control the information surfaced by assistive technology. ARIA can define an element's label, state, properties, and role.
10 |
11 | ARIA is a powerful tool and must be used with care. The [first rule of ARIA](https://www.w3.org/TR/using-aria/#rule1) is to not use ARIA. Use semantic HTML and augment with ARIA. However, we often need to use ARIA to extend HTML or fix inaccessible code. Understanding ARIA is critical for today's web developers.
12 |
13 | ARIA does not make your application accessible. It makes it understandable. You can't put role="button" on a div and expect it to work with a keyboard and screen reader. Adding role="button" simply tells assistive technology to expect the div is actually a button. You would still need to make the div focusable and listen for onkeypress of enter and spacebar. Which is why it's always better to start with a semantic button.
14 |
15 | ### Commonly used ARIA attributes
16 |
17 | - [Roles](https://www.w3.org/TR/wai-aria-1.1/#roles): button, img, link
18 | - [Properties](https://www.w3.org/TR/wai-aria-1.1/#global_states): aria-label, aria-live, aria-haspopup
19 | - [States](https://www.w3.org/TR/wai-aria-1.1/#global_states): aria-required, aria-selected, aria-expanded
20 | - [Landmarks](https://www.w3.org/TR/wai-aria-1.1/#landmark_roles): main, banner, search, region
21 | - [Complex roles](https://www.w3.org/TR/wai-aria-1.1/#widget_roles): alert, tablist, table, toolbar
22 |
23 | You will find ARIA examples within the Tutorial pages.
24 |
--------------------------------------------------------------------------------
/docs/design/text-size.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Text
3 | sidebar_label: 3.4. Text
4 | id: text
5 | ---
6 |
7 | People with low vision use browser zoom tools and assistive technology such as
8 | [ZoomText](http://www.aisquared.com/products/zoomtext/) to increase the size of
9 | content on the screen. This exercise shows you the difference between zooming
10 | all the content versus zooming just the text on the page.
11 |
12 | ## Text size
13 |
14 | For people with low vision, it is important to support the ability to increase
15 | text size without text overlapping or getting truncated. To test, use your browser's
16 | built-in zoom or text-resize feature to zoom and make sure text is still readable.
17 | If you are building for the mobile web, please don't disable pinch and zoom.
18 |
19 | [WCAG guidelines recommend allowing zooming up to 200% without loss of
20 | content.](http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-scale)
21 |
22 | [More on fonts and accessibility in the WebAIM
23 | site.](http://webaim.org/techniques/fonts/#font_size)
24 |
25 | For the exercise below, you will need a browser like Safari that allows you to
26 | increase just the text size instead of zooming in the whole page. On Safari,
27 | go to View and Zoom Text Only and then select Zoom In from the same menu. You
28 | will notice that the words bleed outside the box below. Try fixing this example
29 | by specifying the width and height as relative units, such as ems. Set the height
30 | to 3em and width to 10em and verify your answers.
31 |
32 | import { Editor } from "../_util/Editor.mdx"
33 |
34 | {
36 | const container = exercise.querySelector("#container")
37 | const isValid =
38 | container.style.height === "3em" && container.style.width === "10em"
39 | if (!isValid) {
40 | return "It doesn't seem like the height and width are set to the right ems"
41 | }
42 | }}
43 | >
44 | {`
48 | Lorem ipsum dolor sit amet
49 | `}
50 |
51 |
--------------------------------------------------------------------------------
/docs/design/photos.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Photos
3 | sidebar_label: 3.6. Photos
4 | id: photos
5 | ---
6 |
7 | While alt-text can make a static photo or graphic accessible to screen reader users, when an image is dynamic (e.g., animated GIF or video) and contains audio, additional support is required for users who are blind or deaf.
8 |
9 |
10 |
12 |
13 |
14 | When providing video, via either an embedded or standalone video player, the controls of that player need to be operable by a keyboard-only user (i.e., without a mouse). Controls such as play, pause, fast forward, rewind and scrub bars and closed caption buttons all need to be labeled properly and available to a screen reader user in the same way any web page is made accessible.
15 |
16 | "Audio description" (also known as "video description") provides an added narrative track that describes key visual elements of a animation or video or movie. Timed to be heard during pauses in dialog, descriptions can be recorded and synchronized with the video or made available as text to be read by a screen reader. With HTML5 video players and the video and track elements, audio descriptions can even be heard while a video is automatically paused. For more on how to deliver descriptions, see the following resources:
17 |
18 | -
20 | -
26 |
--------------------------------------------------------------------------------
/docs/introduction/using-this-tutorial.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Using this tutorial
3 | sidebar_label: 1.1. Using this tutorial
4 | id: using-this-tutorial
5 | slug: /
6 | ---
7 |
8 | Welcome to the Teach Access Tutorial! This resource is part of the Teach Access Initiative, and provides best practices for making accessible mobile and web apps. This tutorial currently provides basic training for developers and designers, with more disciplines to come! If you are new to accessibility, you've come to the right place - the following material will help you get a solid footing on accessibility via hands-on exercises and useful reference guides. Follow the instructions below for using and interacting with the tutorial.
9 |
10 | 1. You can use the left and right arrow keys to navigate through the slides.
11 |
12 | 1. Each slide has some core concepts, code samples, and one or more exercises. After you complete an exercise,
13 | use the verify button to check whether your solution is correct.
14 |
15 | 1. You can also verify the code sample output using VoiceOver - Apple's built-in screen reader (other screen readers work too). Here are some instructions for navigating with VoiceOver:
16 |
17 | - cmd + F5 turns VoiceOver on/off
18 | - tab navigates to an interactive element
19 | - ctrl + opt + right arrow (repeatedly)
20 | navigates to the next element
21 | - ctrl + opt + cmd + h
22 | (repeatedly) navigates by headings
23 |
24 | **Please note:** the majority of people who use a screen reader [prefer JAWS or NVDA on a Windows machine](https://webaim.org/projects/screenreadersurvey9/#primary). WebAim has great articles about testing your code with [NVDA](https://webaim.org/articles/nvda/) and [JAWS.](https://webaim.org/articles/jaws/)
25 |
26 | 1. When verifying with VoiceOver, use Chrome on a Mac for the best experience. However, the "Verify" button provided after each exercise will work with any browser/OS combination.
27 |
28 | 1. ARIA stands for Accessible Rich Internet Applications, a W3C standard for
29 | building accessible user interfaces on the web.
30 |
31 | Happy learning!
32 |
--------------------------------------------------------------------------------
/docs/_util/Editor.mdx:
--------------------------------------------------------------------------------
1 | import { EditorView, basicSetup } from "@codemirror/basic-setup";
2 | import { EditorState } from "@codemirror/state";
3 | import { html } from "@codemirror/lang-html";
4 | import parse from "html-react-parser";
5 | import { VerifyButton } from "../_util/VerifyButton.mdx";
6 |
7 | export const Editor = ({ checkExercise, children: initialHtml = "" }) => {
8 | const [editorId] = React.useState(Math.round(Math.random() * 100000));
9 | const [view, setView] = React.useState();
10 | const [output, setOutput] = React.useState(initialHtml);
11 | const resultRef = React.useRef();
12 | React.useEffect(() => {
13 | const editorView = new EditorView({
14 | state: EditorState.create({
15 | doc: initialHtml,
16 | extensions: [
17 | basicSetup,
18 | html(),
19 | EditorView.updateListener.of((v) => {
20 | if (v.docChanged) {
21 | setOutput(v.state.doc.toString());
22 | }
23 | }),
24 | ],
25 | }),
26 | parent: document.querySelector(`#editor-${editorId}`),
27 | });
28 | setView(editorView);
29 | }, []);
30 | const renderEditor = (
31 |
32 | Live editor
33 |
37 |
38 | );
39 | const renderResult = (
40 |
41 | Result
42 |
48 |
49 | );
50 | const renderVerifyButton = checkExercise && (
51 | checkExercise(resultRef.current)} />
52 | );
53 | return (
54 | <>
55 |
56 | {renderEditor}
57 | {renderResult}
58 |
59 | {renderVerifyButton}
60 |
61 | );
62 | };
63 |
--------------------------------------------------------------------------------
/docs/code/keyboard-navigation.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Keyboard navigation
3 | sidebar_label: 2.4. Keyboard navigation
4 | id: keyboard-navigation
5 | ---
6 |
7 | Make all interactive elements work with a keyboard. For example, make sure a
8 | button that you activate with a click is also in the keyboard tab sequence and that pressing enter or space
9 | activates it. Set the `tabindex` attribute to `0` to include an element in the
10 | browser's keyboard tab sequence. If you want an element out of sequence, set
11 | its `tabindex` to `-1` and use JavaScript to control its focus and tab
12 | sequence, and related keyboard events. We do not recommend using `tabindex`
13 | values greater than `0` even though browsers support them. Note that HTML links
14 | and input elements have an implied `tabindex` of `0`.
15 |
16 | ## Semantic button
17 |
18 | The button below uses a semantic `button` tag and is correctly announced by
19 | screen readers. If you are on a Mac, turn on VoiceOver and tab to the
20 | button. You will hear the name of the element and the element type announced
21 | by VoiceOver.
22 |
23 |
24 | {``}
27 |
28 |
29 | ## Exercise: Unsemantic button
30 |
31 | The button below is constructed using an unsemantic `div`. The easiest way to
32 | make this semantic is to use a real `button` or `input` tag. Here is another way. In the
33 | example below, add
34 |
35 | 1. `role='button'`
36 | 1. `tabindex='0'`
37 |
38 | Verify with VoiceOver that you can tab to the button and hear the button name and the fact
39 | that it is a button element. Note that you would need to add an `onkeypress` or `onkeydown` handler to the button so you can tab to the button and press enter to activate it using just the keyboard.
40 |
41 | import { Editor } from "../_util/Editor.mdx"
42 |
43 | {
45 | const [button] = exercise.getElementsByClassName("customButton")
46 | const isValid =
47 | button.hasAttribute("tabindex") &&
48 | button.getAttribute("tabindex") === "0" &&
49 | button.getAttribute("role") === "button"
50 | if (!isValid) {
51 | return "It doesn't look like your custom button is accessible yet."
52 | }
53 | }}
54 | >
55 | {`
56 | Submit
57 | `}
58 |
59 |
--------------------------------------------------------------------------------
/docs/code/landmarks.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Landmarks
3 | sidebar_label: 2.11. Landmarks
4 | id: landmarks
5 | ---
6 |
7 | For this exercise, we will focus on one small part of WAI-ARIA called landmark regions. Landmark regions help screen reader users do what others do when they glance at a page, i.e., see its different parts from a bird’s-eye view. They also make it easy to move the screen reader’s reading cursor to different locations on the page.
8 |
9 | 1. Turn on VoiceOver.
10 | 2. Press `Ctrl` + `Opt` + `u`.
11 | 3. Press right arrow until you hear “Landmarks”.
12 | 4. Press down arrow to read the landmark list.
13 | 5. Press enter to move the VoiceOver reading cursor to the beginning of one of the landmark regions.
14 |
15 | ## Exercise: ARIA landmarks
16 |
17 | import { Editor } from "../_util/Editor.mdx"
18 |
19 | {
21 | const { value } = exercise.getElementById("landmarks")
22 | const isValid = value === "4" || value === "four"
23 | if (!isValid) {
24 | return "That is not the right number of landmarks on the page!"
25 | }
26 | }}
27 | >
28 | {`How many landmarks did you find on the page?
29 | `}
30 |
31 |
32 | There are several types of landmark roles. Some of them are:
33 |
34 | - ``, `
A fake heading
`}
20 |
25 | `}
25 | `}
43 |
48 | Lorem ipsum dolor sit amet
49 |
`}
50 |
12 |
32 |
38 | );
39 | const renderResult = (
40 | Live editor
33 |
37 |
41 |
49 | );
50 | const renderVerifyButton = checkExercise && (
51 | Result
42 |
48 |
56 | {renderEditor}
57 | {renderResult}
58 |
59 | {renderVerifyButton}
60 |
61 | );
62 | };
63 |
--------------------------------------------------------------------------------
/docs/code/keyboard-navigation.mdx:
--------------------------------------------------------------------------------
1 | ---
2 | title: Keyboard navigation
3 | sidebar_label: 2.4. Keyboard navigation
4 | id: keyboard-navigation
5 | ---
6 |
7 | Make all interactive elements work with a keyboard. For example, make sure a
8 | button that you activate with a click is also in the keyboard tab sequence and that pressing enter or space
9 | activates it. Set the `tabindex` attribute to `0` to include an element in the
10 | browser's keyboard tab sequence. If you want an element out of sequence, set
11 | its `tabindex` to `-1` and use JavaScript to control its focus and tab
12 | sequence, and related keyboard events. We do not recommend using `tabindex`
13 | values greater than `0` even though browsers support them. Note that HTML links
14 | and input elements have an implied `tabindex` of `0`.
15 |
16 | ## Semantic button
17 |
18 | The button below uses a semantic `button` tag and is correctly announced by
19 | screen readers. If you are on a Mac, turn on VoiceOver and tab to the
20 | button. You will hear the name of the element and the element type announced
21 | by VoiceOver.
22 |
23 |
56 | Submit
57 |
`}
58 |