You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a number of tools we can use to assist in the creation of accessible web applications.
@@ -15,6 +28,12 @@ By far the easiest and also one of the most important checks is to test if your
15
28
3. Using `Enter` to activate elements.
16
29
4. Where required, using your keyboard arrow keys to interact with some elements, such as menus and dropdowns.
17
30
31
+
::: info
32
+
33
+
Note that not everything has to be interactive for screen readers (e.g. headings)!
34
+
35
+
:::
36
+
18
37
## Increase text size to 200%!
19
38
20
39
Is the content still readable? Does increasing the text size cause content to overlap?
@@ -38,3 +57,161 @@ How do we test to ensure there are minimal to no proximity issues with our desig
38
57
See the Pen <a href="https://codepen.io/svinkle/pen/LrqNPV/">Better Proximity</a> by Scott Vinkle
39
58
(<a href="https://codepen.io/svinkle">@svinkle</a>) on <a href="https://codepen.io">CodePen</a>.
40
59
</iframe>
60
+
61
+
62
+
## Modals
63
+
64
+
Modals are a big one. Anything that opens as a layer on top of other content has accessibility requirements, including:
65
+
66
+
- Sending focus into the new content when it opens.
67
+
- Restoring focus to the element the user was on previously when closing the layer.
68
+
- Preventing keyboard and screen reader interaction with elements in the background.
69
+
- Using a `dialog` role, focusable and labeled buttons and CTAs.
70
+
71
+
Non-modal dialogs don’t have all of the same background requirements. But the goal is still to move focus into relevant content when a non-modal dialog opens and closes.
72
+
73
+
<tapsi-button @click="openModal" variant="brand" id="open-modal-btn">Open a sample modal</tapsi-button>
74
+
<tapsi-modalstyle="z-index: 999"id="sample-modal"heading="a sample modal"description="As you can see. the focus is now on the first focusable element inside the modal.">
It’s real easy to add a click event to a `div`. Too easy, in fact. And it happens all the time! the problem is, `div`s are not interactive elements so you have to backfill quite a few things to make them accessible. All the while, you could have just used a `<button>` element and been done with it.
84
+
85
+
::: details What if we really need to be a `div` button creator?!
86
+
87
+
First, do the easiest part!
88
+
89
+
```tsx
90
+
const MyComponent = () => {
91
+
const fn = () => {
92
+
console.log("clicked on the div!")
93
+
}
94
+
95
+
return (
96
+
<div
97
+
onClick={fn}// [!code focus]
98
+
>
99
+
click!
100
+
</div>
101
+
)
102
+
}
103
+
```
104
+
105
+
Then we set a `role="button"` attribute. based on [MDN documentation](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/button_role):
106
+
107
+
> The button role is for clickable elements that trigger a response when activated by the user. Adding role="button" tells the screen reader the element is a button, but provides no button functionality.
108
+
109
+
110
+
```tsx
111
+
const MyComponent = () => {
112
+
const fn = () => {
113
+
console.log("clicked on the div!")
114
+
}
115
+
116
+
return (
117
+
<div
118
+
role="button"// [!code focus]
119
+
onClick={fn}
120
+
>
121
+
click!
122
+
</div>
123
+
)
124
+
}
125
+
```
126
+
127
+
Now we need should pass key down event handler for keyboard interaction:
if (event.code==='Space'||event.code==='Enter') { // [!code focus]
137
+
fn(); // [!code focus]
138
+
} // [!code focus]
139
+
} // [!code focus]
140
+
141
+
return (
142
+
<div
143
+
role="button"
144
+
onClick={fn}
145
+
onKeyDown={handleKeyDown}// [!code focus]
146
+
>
147
+
click!
148
+
</div>
149
+
)
150
+
}
151
+
```
152
+
153
+
We are not done yet! The element can trigger the `fn` function using `Enter` and `Space` keys, but the problem is the element is not focusable and we should bass a `tabIndex` attribute to the `div` element.
154
+
155
+
```tsx
156
+
const MyComponent = () => {
157
+
const fn = () => {
158
+
console.log("clicked on the div!")
159
+
}
160
+
161
+
const handleKeyDown = (e:KeyboardEvent) => {
162
+
if (event.code==='Space'||event.code==='Enter') {
163
+
fn();
164
+
}
165
+
}
166
+
167
+
return (
168
+
<div
169
+
role="button"
170
+
onClick={fn}
171
+
onKeyDown={handleKeyDown}
172
+
tabIndex="0"// [!code focus]
173
+
>
174
+
click!
175
+
</div>
176
+
)
177
+
}
178
+
```
179
+
180
+
**QUESTION**: Wasn't it eassier to use the following approach instead?
181
+
182
+
```tsx
183
+
const MyComponent = () => {
184
+
const fn = () => {
185
+
console.log("clicked on the div!")
186
+
}
187
+
188
+
return <buttononClick={fn}>click!</div>
189
+
}
190
+
```
191
+
192
+
That’s it. No explicit button `role`, no `tabIndex`, no key handler (because buttons will fire from clicks with the keyboard, unlike `div`s)
193
+
194
+
:::
195
+
196
+
## Use `prefer-reduce-motion` for your animations!
197
+
198
+
::: danger Warning
199
+
200
+
An embedded example in this section has a scaling movement that may be problematic for some readers. Readers with [vestibular motion disorders](https://www.a11yproject.com/posts/understanding-vestibular-disorders/) may wish to enable the reduce motion feature on their device before viewing the animation.
201
+
202
+
:::
203
+
204
+
The `prefers-reduced-motion` CSS media feature is used to detect if a user has enabled a setting on their device to minimize the amount of non-essential motion. The setting is used to convey to the browser on the device that the user prefers an interface that removes, reduces, or replaces motion-based animations.
205
+
206
+
Such animations can trigger discomfort for those with vestibular motion disorders. Animations such as scaling or panning large objects can be vestibular motion triggers.
See the Pen <a href="https://codepen.io/amir78729/pen/myJmQZR">
210
+
Untitled</a> by Amirhossein Alibakhshi (<a href="https://codepen.io/amir78729">@amir78729</a>)
211
+
on <a href="https://codepen.io">CodePen</a>.
212
+
</iframe>
213
+
214
+
215
+
## Accessible Media
216
+
217
+
Make note of any media in need of [captions](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Audio_and_video_delivery/Adding_captions_and_subtitles_to_HTML5_video), [transcripts](https://www.w3.org/WAI/media/av/transcripts/), and other alternative content.
Our React applications continuously modify the HTML DOM during runtime, sometimes leading to keyboard focus being lost or set to an unexpected element. In order to repair this, we need to programmatically nudge the keyboard focus in the right direction. For example, by resetting keyboard focus to a button that opened a modal window after that modal window is closed.
@@ -129,4 +129,4 @@ A great focus management example is the [react-aria-modal](https://github.com/d
129
129
130
130
::: warning
131
131
While this is a very important accessibility feature, it is also a technique that should be used judiciously. Use it to repair the keyboard focus flow when it is disturbed, not to try and anticipate how users want to use applications.
0 commit comments