forked from w3c/aria-practices
-
Notifications
You must be signed in to change notification settings - Fork 0
/
aria-practices.html
3601 lines (3268 loc) · 226 KB
/
aria-practices.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>WAI-ARIA Authoring Practices 1.1</title>
<script src="https://www.w3.org/Tools/respec/respec-w3c-common" class="remove"></script>
<script src="common/script/resolveReferences.js" class="remove"></script>
<script src="common/biblio.js" class="remove"></script>
<script src="respec-config.js" class="remove"></script>
<link href="common/css/common.css" rel="stylesheet" type="text/css" />
</head>
<body>
<section id="abstract">
<p>
This document provides readers with an understanding of how to use <cite><a href="http://www.w3.org/TR/wai-aria-1.1/"><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 1.1</a></cite> [[WAI-ARIA]] to create accessible rich internet applications.
It describes considerations that might not be evident to most authors from the WAI-ARIA specification alone and recommends approaches to make widgets, navigation, and behaviors accessible using WAI-ARIA roles, states, and properties.
This document is directed primarily to Web application developers, but the guidance is also useful for user agent and assistive technology developers.
</p>
<p>This document is part of the WAI-ARIA suite described in the <a href="http://www.w3.org/WAI/intro/aria.php">WAI-ARIA Overview</a>.</p>
</section>
<section id="sotd">
<p>
This is an editor's draft by the
<a href="http://www.w3.org/WAI/ARIA/">Accessible Rich Internet Applications Working Group</a>
of the
<a href="http://www.w3.org/WAI/">Web Accessibility Initiative</a>.
It supports the
<a href="" class="specref">WAI-ARIA 1.1</a> [<cite><a href="#bib-WAI-ARIA" class="bibref">WAI-ARIA</a></cite>]
specification, providing detailed advice and examples beyond what would be appropriate to a technical specification but which are important to understand the specification.
</p>
<p>
This draft includes only a portion of content planned for WAI-ARIA Authoring Practices 1.1.
To see planns for the complete guide, review the
<a href="https://github.com/w3c/aria-practices/milestones?direction=asc&sort=due_date&state=open">Authoring Practices Milestone Plan</a>.
</p>
<p>
Feedback on the information provided here is essential to the ultimate success of Rich Internet Applications that afford full access to their information and operations.
The Accessible Rich Internet Applications Working Group asks in particular:
</p>
<ul>
<li>Is it clear how to create accessible Rich Internet Applications?</li>
<li>Is the usage of roles, states, and properties clear? </li>
<li>Are the various types of rich Web content covered? </li>
<li>Are considerations beyond the use of WAI-ARIA sufficiently explained? </li>
<li>Is the relationship of this document to the WAI-ARIA specification clear? </li>
<li>Are the <a href="#aria_ex">design patterns</a> clear?</li>
</ul>
<p>
To comment,
<a href="https://github.com/w3c/aria-practices/issues/">file an issue in the <abbr title="World Wide Web Consortium">W3C</abbr> ARIA Practices GitHub repository</a>,
or if that is not possible, send email to
<a href="mailto:[email protected]?subject=Comment%20on%20WAI-ARIA%20Practices%201.1">[email protected]</a>
(<a href="http://lists.w3.org/Archives/Public/public-aria/">comment archive</a>).
</p>
</section>
<section id="intro">
<h2>Introduction</h2>
<p>This section is <em>informative.</em></p>
<p>
WAI-ARIA Authoring Practices is a guide to understanding how to use WAI-ARIA to create an accessible Rich Internet Application.
It describes recommended WAI-ARIA usage patterns and provides an introduction to the concepts behind them.
</p>
<p>
This guide is one part of a suite of resources that support the WAI-ARIA specification.
The WAI-ARIA suite fills accessibility gaps identified by the [[WAI-ARIA-ROADMAP]].
</p>
<p>
As explained in <a href="#ariaBackground">Background on WAI-ARIA</a>, languages used to create rich and dynamic web sites, e.g., HTML, Javascript, CSS, and SVG, do not natively include all the features required to make sites usable by people who use assistive technologies (AT) or who rely on keyboard navigation.
The W3C Web Accessibility Initiative's (WAI) Accessible Rich Internet Applications working group (ARIA WG) is addressing these deficiencies through several W3C standards efforts, with a focus on the WAI-ARIA specifications.
For an introduction to WAI-ARIA, see the <a href="http://www.w3.org/WAI/intro/aria.php">Accessible Rich Internet Applications Suite (WAI-ARIA) Overview</a>.
</p>
<p>
With the understanding many prefer to learn from examples, the guide begins with a section that demonstrates how to make common widgets accessible with descriptions of expected behaviors supported by working code.
Where it is helpful to do so, the examples refer to detailed explanations of supporting concepts in subsequent sections.
The sections that follow the examples first provide background that helps build understanding of how WAI-ARIA works and how it fits into the larger web technology picture.
Next, the guide covers general steps for building an accessible widget using WAI-ARIA, JavaScript, and CSS, including detailed guidance on how to make rich internet applications keyboard accessible.
The scope then widens to include the full application, addressing the page layout and structural semantics critical to enabling a usable experience with assistive technologies on pages containing both rich applications and rich documents.
It includes guidance on dynamic document management, use of WAI-ARIA Form properties, and the creation of WAI-ARIA-enabled alerts and dialogs.
</p>
</section>
<section id="aria_ex">
<h2>Design Patterns and Widgets</h2>
<p>This section demonstrates how to make common rich internet application widgets and patterns accessible by applying WAI-ARIA roles, states, and properties and implementing keyboard support.</p>
<p class="note">
Although users of Mac OS X are familiar with using the <kbd>Command</kbd> key instead of the <kbd>Control</kbd> key, the <kbd>Command</kbd> key is typically reserved for desktop applications and OS-level integration.
Until device and platform independence can be addressed in WAI-ARIA 2.0, the primary <kbd>Control</kbd> modifier key for WAI-ARIA widget interaction is specified as <kbd>Control</kbd> on all platforms, including Mac OS X.
</p>
<section id="aria_ex_widget">
<h3>Generally Applicable Keyboard Recommendations </h3>
<p>The following keyboard conventions are applicable to many of the patterns described in subsequent sections.</p>
<ul>
<li><kbd>Shift + F10</kbd> opens associated context menu</li>
<li><kbd>Control + C</kbd> Copies to clipboard </li>
<li><kbd>Control + V</kbd> Pastes from clipboard </li>
<li><kbd>Control + X</kbd> Copies to clipboard and cuts </li>
<li><kbd>Control + Z</kbd> undo last action</li>
<li><kbd>Control + Y</kbd> Redo action</li>
</ul>
</section>
<section class="widget" id="accordion">
<h3>Accordion (Sections With Show/Hide Functionality)</h3>
<p>
An accordion is a vertically stacked set of elements, such as labels or thumbnails, that allow the user to toggle the display of sections of content.
Each labeling element can be expanded or collapsed to reveal or hide its associated content.
Accordions are commonly used to reduce the need to scroll when presenting multiple sections of content on a single page.
</p>
<p>Terms for understanding accordions include:</p>
<dl>
<dt>Accordion Header:</dt>
<dd>Label for or thumbnail representing a section of content that also serves as a control for showing, and in some implementations, hiding the section of content. </dd>
<dt>Accordion Panel:</dt>
<dd>Section of content associated with an accordion header.</dd>
</dl>
<p>
In some accordions, there are additional elements that are always visible adjacent to the accordion header.
For instance, a menubutton may accompany each accordion header to provide access to actions that apply to that section.
And, in some cases, a snippet of the hidden content may also be visually persistent.
</p>
<section class="notoc">
<h4>Keyboard Interaction</h4>
<ul>
<li>
<kbd>Enter</kbd> or <kbd>Space</kbd>:
<ul>
<li>
When focus is on the accordion header for a collapsed panel, expands the associated panel.
If the implementation allows only one panel to be expanded, and if another panel is expanded, collapses that panel.
</li>
<li>
When focus is on the accordion header for an expanded panel, collapses the panel if the implementation supports collapsing.
Some implementations require one panel to be expanded at all times and allow only one panel to be expanded; so, they do not support a collapse function.
</li>
</ul>
</li>
<li>
<kbd>Down Arrow</kbd> (Optional): If focus is on an accordion header, moves focus to the next accordion header.
If focus is on the last accordion header, either does nothing or moves focus to the first accordion header.
</li>
<li>
<kbd>Up Arrow</kbd> (Optional): If focus is on an accordion header, moves focus to the previous accordion header.
If focus is on the first accordion header, either does nothing or moves focus to the last accordion header.
</li>
<li>
<kbd>Home</kbd> (Optional): When focus is on an accordion header, moves focus to the first accordion header.
</li>
<li>
<kbd>End</kbd> (Optional): When focus is on an accordion header, moves focus to the last accordion header.
</li>
<li>
<kbd>Control + Page Down</kbd> (Optional): If focus is inside an accordion
panel or on an accordion header, moves focus to the next accordion header.
If focus is in the last accordion header or panel, either does nothing or
moves focus to the first accordion header.
</li>
<li>
<kbd>Control + Page Up</kbd> (Optional): If focus is inside an accordion panel, moves focus to the header for that panel.
If focus is on an accordion header, moves focus to the previous accordion header.
If focus is on the first accordion header, either does nothing or moves focus to the last accordion header.
</li>
</ul>
</section>
<section class="notoc">
<h4>WAI-ARIA Roles, States, and Properties:</h4>
<ul>
<li>
The title of each accordion header is contained in an element with role <a href="#button" class="role-reference">button</a>.
</li>
<li>
Each accordion header <code>button</code> is wrapped in an element with role <a href="#heading" class="role-reference">heading</a> that has a value set for <a href="#aria-level" class="property-reference">aria-level</a> that is appropriate for the information architecture of the page.
<ul>
<li>If the native host language has an element with an implicit <code>heading</code> and <code>aria-level</code>, such as an HTML heading tag, a native host language element may be used.</li>
<li>
The <code>button</code> element is the only element inside the <code>heading</code> element.
That is, if there are other visually persistent elements, they are not included inside the <code>heading</code> element.
</li>
</ul>
</li>
<li>
If the accordion panel associated with an accordion header is visible, the header <code>button</code> element has <a href="#aria-expanded" class="state-reference">aria-expanded</a> set to <code>true</code>.
If the panel is not visible, <a href="#aria-expanded" class="state-reference">aria-expanded</a> is set to <code>false</code>.
</li>
<li>
The accordion header <code>button</code> element has <a href="#aria-controls" class="property-reference">aria-controls</a> set to the ID of the element containing the accordion panel content.
</li>
<li>
If the accordion panel associated with an accordion header is visible, and if the accordion does not permit the panel to be collapsed, the header <code>button</code> element has <a href="#aria-disabled" class="state-reference">aria-disabled</a> set to <code>true</code>.
</li>
<li>
Optionally, each element that serves as a container for panel content has role
<a href="#region" class="role-reference">region</a> and
<a href="#aria-labelledby" class="property-reference">aria-labelledby</a>
with a value that refers to the button that controls display of the panel.
<ul>
<li>
Avoid using the <code>region</code> role in circumstances that create landmark region proliferation,
e.g., in an accordion that contains more than approximately 6 panels that can be expanded at the same time.
</li>
<li>
Role <code>region</code> is especially helpful to the perception of structure by screen reader users when panels contain heading elements or a nested accordion.
</li>
</ul>
</li>
</ul>
</section>
<section class="notoc">
<h4>Example</h4>
<p><a href="examples/accordion/accordion.html">Accordion Example</a>: demonstrates a form divided into three sections using an accordion to show one section at a time. </p>
</section>
</section>
<section class="widget" id="alert">
<h3>Alert</h3>
<p>
An <a class="role-reference" href="#alert">alert</a> is an element that displays a brief, important message in a way that attracts the user's attention without interrupting the user's task.
Dynamically rendered alerts are automatically announced by most screen readers, and in some operating systems, they may trigger an alert sound.
It is important to note that, at this time, screen readers do not inform users of alerts that are present on the page before page load completes.
</p>
<p>
Because alerts are intended to provide important and potentially time-sensitive information without interfering with the user's ability to continue working,
it is crucial they do not affect keyboard focus.
The <a href="#alertdialog">alert dialog</a> is designed for situations where interrupting work flow is necessary.
</p>
<p>
It is also important to avoid designing alerts that disappear automatically.
An alert that disappears too quickly can lead to failure to meet
<a href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-no-exceptions.html">WCAG 2.0 success criterion 2.2.3</a>.
Another critical design consideration is the frequency of interruption caused by alerts.
Frequent interruptions inhibit usability for people with visual and cognitive disabilities, which makes meeting the requirements of
<a href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-postponed.html">WCAG 2.0 success criterion 2.2.4</a>
more difficult.
</p>
<section class="notoc">
<h4>Keyboard Interaction</h4>
<p>An alert (WAI-ARIA live region) does not require any keyboard interaction.</p>
</section>
<section class="notoc">
<h4>WAI-ARIA Roles, States, and Properties</h4>
<p>The widget has a role of <a class="role-reference" href="#alert">alert</a>.</p>
</section>
<section class="notoc">
<h4>Example</h4>
<p><a href="examples/alert/index.html">Alert Example</a></p>
</section>
</section>
<section class="widget" id="alertdialog">
<h3>Alert and Message Dialogs</h3>
<p>
An alert dialog is a <a href="#dialog_modal">modal dialog</a> that interrupts the user's workflow to communicate an important message and acquire a response.
Examples include action confirmation prompts and error message confirmations.
The <a href="#alertdialog" class="role-reference">alertdialog</a> role
enables assistive technologies and browsers to distinguish alert dialogs from other dialogs
so they have the option of giving alert dialogs special treatment, such as playing a system alert sound.
</p>
<section class="notoc">
<h4>Keyboard Interaction</h4>
<p>See the keyboard interaction section for the <a href="#dialog_modal">modal dialog pattern</a>.</p>
</section>
<section class="notoc">
<h4>WAI-ARIA Roles, States, and Properties</h4>
<ul>
<li>
The element that contains all elements of the dialog, including the alert
message and any dialog buttons, has role
<a class="role-reference" href="#alertdialog">alertdialog</a>.
</li>
<li>
The element with role <code>alertdialog</code> has either:
<ul>
<li>
A value for
<a href="#aria-labelledby" class="property-reference">aria-labelledby</a>
that refers to the element containing the title of the dialog if the
dialog has a visible title.
</li>
<li>
A value for
<a href="#aria-label" class="property-reference">aria-label</a>
if the dialog does not have a visible title.
</li>
</ul>
</li>
<li>
The element with role <code>alertdialog</code> has a value set for
<a href="#aria-describedby" class="property-reference">aria-describedby</a>
that refers to the element containing the alert message.
</li>
</ul>
</section>
<section class="notoc">
<h4>Example</h4>
<p>
Developing an example implementation of this pattern is <a href="https://github.com/w3c/aria-practices/issues/101">issue 101</a>.
</p>
</section>
</section>
<section class="widget" id="breadcrumb">
<h3 class="widget-name">Breadcrumb</h3>
<p>
A breadcrumb trail consists of a list of links to the parent pages of the current page in hierarchical order.
It helps users find their place within a website or web application.
Breadcrumbs are often placed horizontally before a page's main content.
</p>
<section class="notoc">
<h4>Keyboard Interaction</h4>
<p>Not applicable.</p>
</section>
<section class="notoc">
<h4>WAI-ARIA Roles, States, and Properties</h4>
<ul>
<li>Breadcrumb trail is contained within a navigation landmark region.</li>
<li>The landmark region is labelled via <a href="#aria-label" class="property-reference">aria-label</a> or <a href="#aria-labelledby" class="property-reference">aria-labelledby</a>.</li>
<li>
The link to the current page has <a href="#aria-current" class="property-reference">aria-current</a> set to <code>page</code>.
If the element representing the current page is not a link, aria-current is optional.
</li>
</ul>
</section>
<section class="notoc">
<h4>Example</h4>
<p><a href="examples/breadcrumb/index.html">Breadcrumb design pattern example</a></p>
</section>
</section>
<section class="widget" id="button">
<h3>Button</h3>
<p>
A <a class="role-reference" href="#button">button</a> is a widget that enables users to trigger an action or event, such as submitting a form, opening a dialog, canceling an action, or performing a delete operation.
A common convention for informing users that a button launches a dialog is to append "…" (ellipsis) to the button label, e.g., "Save as…".
</p>
<p>In addition to the ordinary button widget, WAI-ARIA supports 2 other types of buttons:</p>
<ul>
<li>
Toggle button: A two-state button that can be either off (not pressed) or on (pressed).
To tell assistive technologies that a button is a toggle button, specify a value for the attribute <a href="#aria-pressed" class="state-reference">aria-pressed</a>.
For example, a button labeled mute in an audio player could indicate that sound is muted by setting the pressed state true.
<strong>Important:</strong> it is critical the label on a toggle does not change when its state changes.
In this example, when the pressed state is true, the label remains "Mute" so a screen reader would say something like "Mute toggle button pressed".
Alternatively, if the design were to call for the button label to change from "Mute" to "Unmute," the aria-pressed attribute would not be needed.
</li>
<li>Menu button: as described in the <a href="#menubutton">menu button pattern</a>, a button is revealed to assistive technologies as a menu button if it has the property <a href="#aria-haspopup" class="property-reference">aria-haspopup</a> set to <code>true</code>.</li>
</ul>
<p class="note">
The types of actions performed by buttons are distinctly different from the function of a link (see <a href="#link">link pattern</a>).
It is important that both the appearance and role of a widget match the function it provides.
Nevertheless, elements occasionally have the visual style of a link but perform the action of a button.
In such cases, giving the element role <code>button</code> helps assistive technology users understand the function of the element.
However, a better solution is to adjust the visual design so it matches the function and ARIA role.
</p>
<section class="notoc">
<h4>Keyboard Interaction</h4>
<p>When the button has focus:</p>
<ul>
<li>
<kbd>Space</kbd>: Activates the button.
</li>
<li>
<kbd>Enter</kbd>: Activates the button.
</li>
<li>
Following button activation, focus is set depending on the type of action the button
performs. For example:
<ul>
<li>
If activating the button opens a dialog, the focus moves inside the dialog. (see
<a href="#dialog_modal">dialog pattern</a>)
</li>
<li>If activating the button closes a dialog, focus typically returns to the
button that opened the dialog unless the function performed in the dialog context
logically leads to a different element. For example, activating a cancel button in a
dialog returns focus to the button that opened the dialog. However, if
the dialog were confirming the action of deleting the page from which it was
opened, the focus would logically move to a new context.</li>
<li>If activating the button does not dismiss the current context, then focus
typically remains on the button after activation, e.g., an Apply or
Recalculate button.</li>
<li>If the button action indicates a context change, such as move to next step in
a wizard or add another search criteria, then it is often appropriate to move focus to
the starting point for that action.</li>
<li>
If the button is activated with a shortcut key, the focus usually remains in
the context from which the shortcut key was activated. For example, if <kbd>Alt
+ U</kbd> were assigned to an "Up" button that moves the currently focused
item in a list one position higher in the list, pressing <kbd>Alt + U</kbd> when the
focus is in the list would not move the focus from the list.
</li>
</ul>
</li>
</ul>
</section>
<section class="notoc">
<h4>WAI-ARIA Roles, States, and Properties</h4>
<ul>
<li>The button has role of <a class="role-reference" href="#button">button</a>.</li>
<li>
The <code>button</code> has an accessible label.
By default, the accessible name is computed from any text content inside the button element.
However, it can also be provided with <a href="#aria-labelledby" class="property-reference">aria-labelledby"</a> or <a href="#aria-label" class="property-reference">aria-label</a>.
</li>
<li>If a description of the button's function is present, the button element has <a href="#aria-describedby" class="property-reference">aria-describedby</a> set to the ID of the element containing the description.</li>
<li>When the action associated with a button is unavailable, the button has <a class="state-reference" href="#aria-disabled">aria-disabled</a> set to <code>true</code>.</li>
<li>
If the button is a toggle button, it has an <a href="#aria-pressed" class="state-reference">aria-pressed</a> state.
When the button is toggled on, the value of this state is <code>true</code>, and when toggled off, the state is <code>false</code>.
</li>
</ul>
</section>
<section class="notoc">
<h4>Examples</h4>
<p><a href="examples/button/button.html">Button Examples</a>: Examples of clickable HTML <code>div</code> and <code>span</code> elements made into accessible command and toggle buttons.</p>
</section>
</section>
<section class="widget" id="checkbox">
<h3>Checkbox</h3>
<p>WAI-ARIA supports two types of <a href="#checkbox" class="role-reference">checkbox</a> widgets:</p>
<ol>
<li>Dual-state: The most common type of checkbox, it allows the user to toggle between two choices -- checked and not checked.</li>
<li>Tri-state: This type of checkbox supports an additional third state known as partially checked.</li>
</ol>
<p>
One common use of a tri-state checkbox can be found in software installers where a single tri-state checkbox is used to represent and control the state of an entire group of install options.
And, each option in the group can be individually turned on or off with a dual state checkbox.
</p>
<ul>
<li>If all options in the group are checked, the overall state is represented by the tri-state checkbox displaying as checked.</li>
<li>If some of the options in the group are checked, the overall state is represented with the tri-state checkbox displaying as partially checked.</li>
<li>If none of the options in the group are checked, the overall state of the group is represented with the tri-state checkbox displaying as not checked.</li>
</ul>
<p>The user can use the tri-state checkbox to change all options in the group with a single action:</p>
<ul>
<li>Checking the overall checkbox checks all options in the group.</li>
<li>Unchecking the overall checkbox will uncheck all options in the group.</li>
<li>
And, In some implementations, the system may remember which options were checked the last time the overall status was partially checked.
If this feature is provided, activating the overall checkbox a third time recreates that partially checked state where only some options in the group are checked.
</li>
</ul>
<section class="notoc">
<h4>Keyboard Interaction</h4>
<p>When the checkbox has focus, pressing the <kbd>Space</kbd> key changes the state of the checkbox.</p>
</section>
<section class="notoc">
<h4>WAI-ARIA Roles, States, and Properties</h4>
<ul>
<li>The checkbox has role <a href="#checkbox" class="role-reference">checkbox</a>.</li>
<li>The checkbox has an accessible label, preferably provided by a visible label associated using <a href="#aria-labelledby" class="property-reference" >aria-labelledby</a>.</li>
<li>When checked, the checkbox element has state <a href="#aria-checked" class="state-reference" >aria-checked</a> set to <code>true</code>.</li>
<li>When not checked, it has state <a href="#aria-checked" class="state-reference" >aria-checked</a> set to <code>false</code>.</li>
<li>When partially checked, it has state <a href="#aria-checked" class="state-reference" >aria-checked</a> set to <code>mixed</code>.</li>
<li>If a set of checkboxes is presented as a logical group with a visible label, the checkboxes are included in an element with role <a href="#group" class="role-reference" >group</a> that has the property <a href="#aria-labelledby" class="property-reference" >aria-labelledby</a> set to the ID of the element containing the label.</li>
<li>If the presentation includes additional descriptive static text relevant to a checkbox or checkbox group, the checkbox or checkbox group has the property <a href="#aria-describedby" class="property-reference">aria-describedby</a> set to the ID of the element containing the description.</li>
</ul>
</section>
<section class="notoc">
<h4>Examples</h4>
<ul>
<li>
<a href="examples/checkbox/checkbox-1/checkbox-1.html">Simple Two-State Checkbox Example</a>: Demonstrates a simple 2-state checkbox.
</li>
<li>
<a href="examples/checkbox/checkbox-2/checkbox-2.html">Tri-State Checkbox Example</a>:
Demonstrates how to make a widget that uses the <code>mixed</code> value for <code>aria-checked</code> and group collection of checkboxes with a field set.
</li>
</ul>
</section>
</section>
<section class="widget" id="combobox">
<h3>Combo Box</h3>
<p>Drafting this section is <a href="https://github.com/w3c/aria-practices/issues/31">issue 31</a>. </p>
</section>
<section class="widget" id="dialog_modal">
<h3>Dialog (Modal)</h3>
<p>
<strong>NOTE:</strong> This section has been significantly revised to address initial focus placement and other outstanding editorial issues.
Please provide feedback on this design pattern in
<a href="https://github.com/w3c/aria-practices/issues/325">issue 325.</a>
</p>
<p>
A <a href="#dialog" class="role-reference">dialog</a> is a window overlayed on either the primary window or another dialog window.
Windows under a modal dialog are inert.
That is, users cannot interact with content outside an active dialog window.
Inert content outside an active dialog is typically visually obscured or dimmed so it is difficult to discern,
and in some implementations, attempts to interact with the inert content cause the dialog to close.
</p>
<p>
Like <a href="#dialog_nonmodal">non-modal dialogs</a>, modal dialogs contain their tab sequence.
That is, <kbd>Tab</kbd> and <kbd>Shift + Tab</kbd> do not move focus outside the dialog.
However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.
</p>
<p>
The <a href="#alertdialog" class="role-reference">alertdialog</a> role is a special-case dialog role
designed specifically for dialogs that divert users' attention to a brief, important message.
Its usage is described in the <a href="#alertdialog">alert dialog design pattern.</a>
</p>
<section class="notoc">
<h4>Keyboard Interaction</h4>
<p>In the following description, the term <q>tabbable element</q> refers to any element with a <code>tabindex</code> value of zero or greater. Note that values greater than 0 are strongly discouraged.</p>
<ul>
<li>When a dialog opens, focus moves to an element inside the dialog. See notes below regarding initial focus placement.</li>
<li><kbd>Tab</kbd>:
<ul>
<li>Moves focus to the next tabbable element inside the dialog.</li>
<li>If focus is on the last tabbable element inside the dialog, moves focus to the first tabbable element inside the dialog. </li>
</ul>
</li>
<li><kbd>Shift + Tab</kbd>:
<ul>
<li>Moves focus to the previous tabbable element inside the dialog.</li>
<li>If focus is on the first tabbable element inside the dialog, moves focus to the last tabbable element inside the dialog.</li>
</ul>
</li>
<li><kbd>Escape</kbd>: Closes the dialog.</li>
</ul>
<ol class="note">
<li> When a dialog opens, focus placement depends on the nature and size of the content.
<ul>
<li>In all circumstances, focus moves to an element contained in the dialog.</li>
<li>Unless a condition where doing otherwise is advisable, focus is initially set on the first focusable element.</li>
<li>
If content is large enough that focusing the first interactive element could cause the beginning of content to scroll out of view,
it is advisable to add <code>tabindex=<q>-1</q></code> to a static element at the top of the dialog, such as the dialog title or first paragraph, and initially focus that element.
</li>
<li>
If a dialog contains the final step in a process that is not easily reversible, such as deleting data or completing a financial transaction,
it may be advisable to set focus on the least destructive action, especially if undoing the action is difficult or impossible.
The <a href="#alertdialog">Alert Dialog Pattern</a> is often employed in such circumstances.
</li>
<li>
If a dialog is limited to interactions that either provide additional information or continue processing,
it may be advisable to set focus to the element that is likely to be most frequently used, such as an <q>OK</q> or <q>Continue</q> button.
</li>
</ul>
</li>
<li>
When a dialog closes, focus is set on an element that supports a logical work flow.
If the element that had focus before the dialog was invoked still exists, that element is usually the most appropriate choice.
</li>
<li>It is strongly recommended that the tab sequence of all dialogs include a visible element with role <code>button</code> that closes the dialog, such as a close icon or cancel button.</li>
</ol>
</section>
<section class="notoc">
<h4>WAI-ARIA Roles, States, and Properties</h4>
<ul>
<li>The element that serves as the dialog container has a role of <a href="#dialog" class="role-reference">dialog</a>.</li>
<li>All elements required to operate the dialog are descendants of the element that has role <code>dialog</code>.</li>
<li>The dialog container element has <a href="#aria-modal" class="property-reference">aria-modal</a> set to <code>true</code>.</li>
<li>The dialog has either:
<ul>
<li>A value set for the
<a href="#aria-labelledby" class="property-reference">aria-labelledby</a>
property that refers to a visible dialog title.</li>
<li>A label specified by <a href="#aria-label" class="property-reference">aria-label</a>.</li>
</ul>
</li>
<li>
Optionally, the <a href="#aria-describedby" class="property-reference">aria-describedby</a> property
is set on the element with the <code>dialog</code> role to indicate which element or elements in the dialog contain content that describes the primary purpose or message of the dialog.
Specifying descriptive elements enables screen readers to announce the description along with the dialog title and initially focused element when the dialog opens.
</li>
</ul>
<ul class="note">
<li>
Because marking a dialog modal by setting
<a href="#aria-modal" class="property-reference">aria-modal</a>
to <code>true</code> can prevent users of some assistive technologies from perceiving content outside the dialog,
users of those technologies will experience severe negative ramifications if a dialog is marked modal but is not modal for other users.
So, mark a dialog modal <strong>only when:</strong>
<ol>
<li>Application code prevents all users from interacting in any way with content outside of it.</li>
<li>Visual styling obscures the content outside of it.</li>
</ol>
<li>
The <code>aria-modal</code> property introduced by ARIA 1.1 replaces
<a href="#aria-hidden" class="state-reference">aria-hidden</a>
for informing assistive technologies that content outside a dialog is inert.
However, in legacy dialog implementations where <code>aria-hidden</code> is used to make content outside a dialog inert for assistive technology users, it is important that:
<ol>
<li><code>aria-hidden</code> is set to <code>true</code> on each element containing a portion of the inert layer.</li>
<li>The dialog element is not a descendant of any element that has <code>aria-hidden</code> set to <code>true</code>.</li>
</ol>
</li>
</ul>
</section>
<section class="notoc">
<h4>Example</h4>
<p><a href="examples/dialog-modal/dialog.html">Modal Dialog Example</a></p>
</section>
</section>
<section class="widget" id="dialog_nonmodal">
<h3>Dialog (Non-Modal)</h3>
<p>Drafting content for this section is tracked by <a href="https://github.com/w3c/aria-practices/issues/59">issue 59</a>. </p>
</section>
<section class="widget" id="disclosure">
<h3>Disclosure (Show/Hide)</h3>
<p>
Drafting content for this section is tracked by
<a href="https://github.com/w3c/aria-practices/issues/9">issue 9</a>.
</p>
<p>Write description of disclosure pattern here.</p>
<section class="notoc">
<h4>Keyboard Interaction</h4>
<p>When the disclosure control has focus:</p>
<ul>
<li><kbd>Enter</kbd>: activates the disclosure control and toggles the visibility of the disclosure content.</li>
<li><kbd>Space</kbd>: activates the disclosure control and toggles the visibility of the disclosure content.</li>
</ul>
</section>
<section class="notoc">
<h4>WAI-ARIA Roles, States, and Properties</h4>
<ul>
<li>role <a href="#button" class="role-reference">button</a></li>
<li>state <a href="#aria-expanded" class="state-reference">aria-expanded</a></li>
<li>property <a href="#aria-controls" class="property-reference">aria-controls</a></li>
</ul>
</section>
<section class="notoc">
<h4>Examples</h4>
<ul>
<li><a href="examples/disclosure/disclosure-img-long-description.html">Disclosure (Show/Hide) of Image Description</a></li>
<li><a href="examples/disclosure/disclosure-faq.html">Disclosure (Show/Hide) of Answers to Frequently Asked Questions</a></li>
</ul>
</section>
</section>
<section class="widget" id="feed">
<h3 class="widget-name">Feed</h3>
<p class="note">
This section contains an early draft of new content.
Feedback is welcom in
<a href="https://github.com/w3c/aria-practices/issues/245">issue 245.</a>
</p>
<p>
A feed is a section of a page that automatically loads new content as the user reads.
Content in a feed is segmented into article elements. Thus, it can be thought of as a dynamic list of articles
that often appears to scroll infinitely.
</p>
<p>
The primary difference between a feed and other ARIA patterns that support loading data as users scroll,
e.g., a <a href="#grid">grid</a>, is that a feed is a structure, not a widget. This means assistive
technologies with a reading mode, such as screen readers, will default to reading mode when
interacting with feed content, making the feed pattern most useful for blocks of
unstructured information that may contain links or other interactive elements.
</p>
<p>
For example, a product page on a shopping site may have a related products section that
displays five products at a time. As the user scrolls, more products are requested and loaded into the DOM.
While a static design might include a next button for loading five more products, a dynamic implementation
that automatically loads data as needed simplifies the user
experience and reduces the inertia associated with viewing more than the first five product suggestions.
</p>
<p>
Unfortunately, when web pages load content dynamically based on scroll events, it
creates interoperability difficulties for users of assistive technologies that cannot
sufficiently mimic visual scrolling.
Even if the page also observes focus movements in
order to identify when more content is needed,
there can still be problems because requiring assistive technologies to
move DOM focus in response to every reading cursor movement, regardless of context,
can also negatively impact a screen reading experience.
</p>
<p>
The feed pattern enables reliable assistive technology reading mode interaction by
establishing the following interoperability agreement between the web page and assistive
technologies:
</p>
<ol>
<li>In the context of a feed, the web page code is responsible for:
<ul>
<li>
Appropriate visual scrolling of the content based on which article contains DOM focus.
</li>
<li>Loading or removing feed articles based on which article contains DOM focus.</li>
</ul>
</li>
<li>In the context of a feed, assistive technologies with a reading mode are responsible for:
<ul>
<li>Indicating which article contains the reading cursor by ensuring the article element or one of its descendants has DOM focus.</li>
<li>providing reading mode keys that move DOM focus to the next and previous articles.</li>
<li>Providing reading mode keys for moving the reading cursor and DOM focus past the end and before the start of the feed.</li>
</ul>
</li>
</ol>
<p>
Thus, implementing the feed pattern allows a screen reader to reliably read and trigger the loading
of feed content while staying in its reading mode.
</p>
<p>
Another feature of the feed pattern is its ability to facilitate skim reading for
assistive technology users. Web page authors may provide both an accessible name and
description for each article. By identifying the elements inside of an
article that provide the title and the primary content, assistive technologies can provide
functions that enable users to jump from article to article and efficiently discern which
articles may be worthy of more attention.
</p>
<section class="notoc">
<h4>Keyboard Interaction</h4>
<p>
The feed pattern is not based on a desktop GUI widget so the <code>feed</code> role is not associated with any well-established keyboard conventions.
Supporting the following, or a similar, interface is recommended.
</p>
<p>When focus is inside the feed:</p>
<ul>
<li><kbd>Page Down</kbd>: Move focus to next article.</li>
<li><kbd>Page Up</kbd>: Move focus to previous article.</li>
<li><kbd>Control + End</kbd>: Move focus to the first focusable element after the feed.</li>
<li><kbd>Control + Home</kbd>: Move focus to the first focusable element before the feed.</li>
</ul>
<ol class="note">
<li>Due to the lack of convention, providing easily discoverable keyboard interface documentation is especially important.</li>
<li>
In some cases, a feed may contain a nested feed.
For example, an article in a social media feed may contain a feed of comments on that article.
To navigate the nested feed, users first move focus inside the nested feed.
Options for supporting nested feed navigation include:
<ul>
<li>
Users move focus into the nested feed from the content of the containing article with <kbd>Tab</kbd>.
This may be slow if the article contains a significant number of links, buttons, or other widgets.
</li>
<li>Provide a key for moving focus from the elements in the containing article to the first item in the nested feed, e.g., <kbd>Alt + Page Down</kbd>.</li>
<li>To continue reading the outer feed, <kbd>Control + End</kbd> moves focus to the next article in the outer feed.</li>
</ul>
</li>
<li>In the rare circumstance that a feed article contains a widget that uses the above suggested keys, the feed navigation key will operate the contained widget, and the user needs to move focus to an element that does not utilize the feed navigation keys in order to navigate the feed.</li>
</ol>
</section>
<section class="notoc">
<h4>WAI-ARIA Roles, States, and Properties</h4>
<ul>
<li>The element that contains the set of feed articles has role <a href="#feed" class="role-reference">feed</a>.</li>
<li>
If the feed has a visible title, the <code>feed</code> element has <a href="#aria-labelledby" class="property-reference">aria-labelledby</a> referring to the element containing the title.
Otherwise, the <code>feed</code> element has a label specified with <a href="#aria-label" class="property-reference">aria-label</a>.
</li>
<li>
Each unit of content in a feed is contained in an element with role <a href="#article" class="role-reference">article</a>.
All content inside the feed is contained in an <code>article</code> element.
</li>
<li>
Each <code>article</code> element has
<a href="#aria-labelledby" class="property-reference">aria-labelledby</a>
referring to elements inside the article that can serve as a distinguishing label.
</li>
<li>
It is optional but strongly recommended for Each <code>article</code> element to have
<a href="#aria-describedby" class="property-reference">aria-describedby</a>
referring to one or more elements inside the article that serve as the primary content of the article.
</li>
<li>
Each <code>article</code> element has
<a href="#aria-posinset" class="property-reference">aria-posinset</a>
set to a value that represents its position in the feed.
</li>
<li>
Each <code>article</code> element has
<a href="#aria-setsize" class="property-reference">aria-setsize</a>
set to a value that represents either the total number of articles that have been loaded or the total number in the feed,
depending on which value is deemed more helpful to users.
If the total number in the feed is undetermined, it can be represented by a <code>aria-setsize</code> value of <code>-1</code>.
</li>
<li>
When <code>article</code> elements are being added to or removed from the <code>feed</code> container,
and if the operation requires multiple DOM operations,
the <code>feed</code> element has
<a href="#aria-busy" class="state-reference">aria-busy</a>
set to <code>true</code> during the update operation.
Note that it is extremely important that <code>aria-busy</code> is set to <code>false</code> when the operation is complete or the changes may not become visible to some assistive technology users.
</li>
</ul>
</section>
<section class="notoc">
<h4>Example</h4>
<p>
<a href="examples/feed/feed.html">Example Implementation of Feed Pattern</a>
</p>
</section>
</section>
<section class="widget" id="grid">
<h3>Grids : Interactive Tabular Data and Layout Containers</h3>
<p>
A <a href="#grid" class="role-reference">grid</a> widget is a container that enables users to navigate the information or interactive elements it contains using directional navigation keys, such as arrow keys, <kbd>Home</kbd> , and <kbd>End</kbd>.
As a generic container widget that offers flexible keyboard navigation, it can serve a wide variety of needs.
It can be used for purposes as simple as grouping a collection of checkboxes or navigation links or as complex as creating a full-featured spreadsheet application.
While ARIA properties and assistive technologies use row and column nomenclature when describing and presenting the logical structure of elements with the <code>grid</code> role, using the <code>grid</code> role on an element does not necessarily imply that its visual presentation is tabular.
</p>
<p>When presenting content that is tabular, consider the following factors when choosing between implementing this <code>grid</code> patern or the <a href="#table">table</a> pattern.</p>
<ul>
<li>
A <code>grid</code> is a composite widget so it:
<ul>
<li>Always contains multiple focusable elements. </li>
<li>Has only one focusable element in the page tab sequence.</li>
<li>Requires the author to provide code that <a href="#kbd_general_within">manages focus movement inside it</a>.</li>
</ul>
</li>
<li>All focusable elements contained in a table are included in the page tab sequence. </li>
</ul>
<p>
Uses of the <code>grid</code> pattern broadly fall into two categories: presenting tabular information (data grids) and grouping other widgets (layout grids).
Even though both data grids and layout grids employ the same ARIA roles, states, and properties, differences in their content and purpose surface factors that are important to consider in keyboard interaction design.
To address these factors, the following two sections describe separate keyboard interaction patterns for data and layout grids.
</p>
<section id="dataGrid" class="notoc">
<h4>Data Grids For Presenting Tabular Information</h4>
<p>
A <code>grid</code> can be used to present tabular information that has column titles, row titles, or both.
The <code>grid</code> pattern is particularly useful if the tabular information is editable or interactive.
For example, when data elements are links to more information, rather than presenting them in a static table and including the links in the tab sequence, implementing the <code>grid</code> pattern provides users with intuitive and efficient keyboard navigation of the grid contents as well as a shorter tab sequence for the page.
A <code>grid</code> may also offer functions, such as cell content editing, selection, cut, copy, and paste.
</p>
<p>
In a grid that presents tabular data, every cell contains a focusable element or is itself focusable, regardless of whether the cell content is editable or interactive.
There is one exception: if column or row header cells do not provide functions, such as sort or filter, they do not need to be focusable. One reason this is important is that screen readers need to be in their application reading mode, rather than their document reading mode, while the user is interacting with the grid.
While in application reading mode, a screen reader user can only discover focusable elements and content that labels focusable elements.
So, a screen reader user may unknowningly overlook elements contained in a grid that are either not focusable or not used to label a column or row.
A more detailed description of this topic with examples is available in the section describing <a href="#ScreenReaderModes">screen reader document and application reading modes</a>.
</p>
<section class="notoc">
<h5>Keyboard Interaction For Data Grids</h5>
<p>
The following keys provide grid navigation by moving focus among cells of the grid.
These key commands are available by default after an element in the grid receives focus.
</p>
<ul>
<li>
<kbd>Right Arrow</kbd>: Moves focus one cell to the right.
If focus is on the right-most cell in the row, focus does not move.
</li>
<li><kbd>Left Arrow</kbd>: Moves focus one cell to the left. If focus is on the left-most cell in the row, focus does not move.</li>
<li><kbd>Down Arrow</kbd>: Moves focus one cell down. If focus is on the bottom cell in the column, focus does not move.</li>
<li><kbd>Up Arrow</kbd>: Moves focus one cell Up. If focus is on the top cell in the column, focus does not move.</li>
<li><kbd>Page Down</kbd>: Moves focus down an author-determined number of rows, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows. If focus is in the last row of the grid, focus does not move.</li>
<li><kbd>Page Up</kbd>: Moves focus up an author-determined number of rows, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows. If focus is in the first row of the grid, focus does not move.</li>
<li><kbd>Home</kbd>: moves focus to the first cell in the row that contains focus.</li>
<li><kbd>End</kbd>: moves focus to the last cell in the row that contains focus.</li>
<li><kbd>Control + Home</kbd>: moves focus to the first cell in the first row.</li>
<li><kbd>Control + End</kbd>: moves focus to the last cell in the last row.</li>
</ul>
<ul class="note">
<li>
When the above grid navigation keys move focus, whether the focus is set on an element inside the cell or the grid cell depends on cell content.
See <a href="#gridNav_focus">Whether to Focus on a Cell or an Element Inside It</a>.
</li>
<li>
While navigation keys, such as arrow keys, are moving focus from cell to cell, they are not available to do something like operate a combobox or move an editing caret inside of a cell.
If this functionality is needed, see <a href="#gridNav_inside">Editing and Navigating Inside a Cell</a>.
</li>
<li>If navigation functions can dynamically add more rows or columns to the DOM, key events that move focus to the beginning or end of the grid, such as <kbd>control + End</kbd>, may move focus to the last row in the DOM rather than the last available row in the back-end data.</li>
</ul>
<p>If a grid supports selection of cells, rows, or columns, the following keys are commonly used for these functions.</p>
<ul>
<li><kbd>Control + Space</kbd>: selects the column that contains the focus.</li>
<li><kbd>Shift + Space</kbd>: Selects the row that contains the focus. If the grid includes a column with checkboxes for selecting rows, this key can serve as a shortcut for checking the box when focus is not on the checkbox.</li>
<li><kbd>Control + A</kbd>: Selects all cells.</li>
<li><kbd>Shift + Right Arrow</kbd>: Extends selection one cell to the right.</li>
<li><kbd>Shift + Left Arrow</kbd>: Extends selection one cell to the left.</li>
<li><kbd>Shift + Down Arrow</kbd>: Extends selection one cell down.</li>
<li><kbd>Shift + Up Arrow</kbd>: Extends selection one cell Up.</li>
</ul>
<p class="note">See <a href="#aria_ex_widget">Global Recommendations</a> for cut, copy and paste key assignments.</p>
</section>
</section>
<section id="layoutGrid" class="notoc">
<h4>Layout Grids for Grouping Widgets</h4>
<p>
The <code>grid</code> pattern can be used to group a set of interactive elements, such as links, buttons, or checkboxes.
Since only one element in the entire grid is included in the tab sequence, grouping with a grid can dramatically reduce the number of tab stops on a page.
This is especially valuable if scrolling through a list of elements dynamically loads more of those elements from a large data set, such as in a continuous list of suggested products on a shopping site.
If elements in a list like this were in the tab sequence, keyboard users are effectively trapped in the list.
If any elements in the group also have associated elements that appear on hover, the <code>grid</code> pattern is also useful for providing keyboard access to those contextual elements of the user interface.
</p>
<p>
Unlike grids used to present data, A <code>grid</code> used for layout does not necessarily have header cells for labeling rows or columns and might contain only a single row or a single column.
Even if it has multiple rows and columns, it may present a single, logically homogenous set of elements.
For example, a list of recipients for a message may be a grid where each cell contains a link that represents a recipient.
The grid may initially have a single row but then wrap into multiple rows as recipients are added.
In such circumstances, grid navigation keys may also wrap so the user can read the list from beginning to end by pressing either <kbd>Right Arrow</kbd> or <kbd>Down Arrow</kbd>.
While This type of focus movement wrapping can be very helpful in a layout grid, it would be disorienting if used in a data grid, especially for users of assistive technologies.
</p>
<p>
Because arrow keys are used to move focus inside of a <code>grid</code>, a <code>grid</code> is both easier to build and use if the components it contains do not require the arrow keys to operate.
If a cell contains an element like a <a href="#Listbox">listbox</a>, then an extra key command to focus and activate the listbox is needed as well as a command for restoring the grid navigation functionality.
Aproaches to supporting this need are described in the section on <a href="#gridNav_inside">Editing and Navigating Inside a Cell</a>.
</p>
<section class="notoc">
<h5>Keyboard Interaction For Layout Grids</h5>
<p>
The following keys provide grid navigation by moving focus among cells of the grid.
These key commands are available by default after an element in the grid receives focus.
</p>
<ul>
<li>
<kbd>Right Arrow</kbd>: Moves focus one cell to the right.
Optionally, if focus is on the right-most cell in the row, focus may move to the first cell in the following row.
If focus is on the last cell in the grid, focus does not move.
</li>
<li>
<kbd>Left Arrow</kbd>: Moves focus one cell to the left.
Optionally, if focus is on the left-most cell in the row, focus may move to the last cell in the previous row.
If focus is on the first cell in the grid, focus does not move.
</li>
<li>
<kbd>Down Arrow</kbd>: Moves focus one cell down.
Optionally, if focus is on the bottom cell in the column, focus may move to the top cell in the following column.
If focus is on the last cell in the grid, focus does not move.
</li>
<li>
<kbd>Up Arrow</kbd>: Moves focus one cell up.
Optionally, if focus is on the top cell in the column, focus may move to the bottom cell in the previous column.
If focus is on the first cell in the grid, focus does not move.
</li>
<li>
<kbd>Page Down</kbd> (Optional): Moves focus down an author-determined number of rows, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows.
If focus is in the last row of the grid, focus does not move.
</li>
<li>
<kbd>Page Up</kbd> (Optional): Moves focus up an author-determined number of rows, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows.
If focus is in the first row of the grid, focus does not move.
</li>
<li>
<kbd>Home</kbd>: moves focus to the first cell in the row that contains focus.
Optionally, if the grid has a single column or fewer than three cells per row, focus may instead move to the first cell in the grid.
</li>
<li>
<kbd>End</kbd>: moves focus to the last cell in the row that contains focus.
Optionally, if the grid has a single column or fewer than three cells per row, focus may instead move to the last cell in the grid.
</li>
<li><kbd>Control + Home</kbd> (optional): moves focus to the first cell in the first row.</li>
<li><kbd>Control + End</kbd> (Optional): moves focus to the last cell in the last row.</li>
</ul>
<ul class="note">
<li>
When the above grid navigation keys move focus, whether the focus is sett on an element inside the cell or the grid cell depends on cell content.
See <a href="#gridNav_focus">Whether to Focus on a Cell or an Element Inside It</a>.
</li>
<li>
While navigation keys, such as arrow keys, are moving focus from cell to cell, they are not available to do something like operate a combobox or move an editing caret inside of a cell.
If this functionality is needed, see <a href="#gridNav_inside">Editing and Navigating Inside a Cell</a>.
</li>
<li>If navigation functions can dynamically add more rows or columns to the DOM, key events that move focus to the beginning or end of the grid, such as <kbd>control + End</kbd>, may move focus to the last row in the DOM rather than the last available row in the back-end data.</li>
</ul>
<p>It would be unusual for a layout grid to provide functions that require cell selection. If it did, though, the following keys are commonly used for these functions.</p>
<ul>
<li><kbd>Control + Space</kbd>: selects the column that contains the focus.</li>
<li>
<kbd>Shift + Space</kbd>: Selects the row that contains the focus.
If the grid includes a column with checkboxes for selecting rows, this key can serve as a shortcut for checking the box when focus is not on the checkbox.
</li>
<li><kbd>Control + A</kbd>: Selects all cells.</li>
<li><kbd>Shift + Right Arrow</kbd>: Extends selection one cell to the right.</li>
<li><kbd>Shift + Left Arrow</kbd>: Extends selection one cell to the left.</li>
<li><kbd>Shift + Down Arrow</kbd>: Extends selection one cell down.</li>
<li><kbd>Shift + Up Arrow</kbd>: Extends selection one cell Up.</li>
</ul>
<p class="note">See <a href="#aria_ex_widget">Global Recommendations</a> for cut, copy and paste key assignments.</p>
</section>