discontinued / server · Files

index.html 344 KB
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 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta content="text/html; charset=utf-8" http-equiv="Content-Type"/><title>WAI-ARIA 1.0 Authoring Practices</title><link href="spec.css" rel="stylesheet" type="text/css"/><link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css"/></head><body>
<p align="center">[<a href="#toc">contents</a>]</p>
<div class="head"> <a href="http://www.w3.org/"><img alt="W3C" height="48" src="http://www.w3.org/Icons/w3c_home" width="72"/></a>
	<h1><abbr title="Accessible Rich Internet Applications">WAI-ARIA</abbr> 1.0 Authoring Practices</h1>
  <h2 id="subhead">An author's guide to understanding and implementing Accessible Rich Internet Applications</h2>
  <h2 class="maturity">W3C Working Draft 16 September 2010</h2>
  <dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/">http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/</a></dd><dt>Latest version:</dt><dd> <a href="http://www.w3.org/TR/wai-aria-practices/">http://www.w3.org/TR/wai-aria-practices/</a> </dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2009/WD-wai-aria-practices-20091215/">http://www.w3.org/TR/2009/WD-wai-aria-practices-20091215/</a></dd><dt>Editors: </dt><dd>Joseph Scheuhammer, Invited Expert<br clear="none"/>
      Michael Cooper, W3C<br clear="none"/>
    </dd><dt>Previous Editors:</dt><dd> Lisa Pappas, Society for Technical Communication<br clear="none"/>
Richard Schwerdtfeger, IBM</dd></dl>
  <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2007 - 2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
  <hr title="Separator from Header"/>
</div>
<div id="abstract">
  <h2>Abstract</h2>
	<p>This WAI-ARIA Authoring Practices Guide provides readers with an understanding of how to use <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/">WAI-ARIA</a></cite> [<cite><a href="#ref_ARIA">ARIA</a></cite>] 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. 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>
</div>
<div> <a id="sotd" name="sotd"></a>
  <h2>Status of This Document</h2>
	<p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
	
	
		<p>This  is a  Public Working Draft by the <a href="http://www.w3.org/WAI/PF/">Protocols &amp; Formats
	      Working Group</a> of the <a href="http://www.w3.org/WAI/">Web Accessibility
	      Initiative</a>. It supports the <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/">Accessible
	      Rich Internet Applications (WAI-ARIA)</a></cite> [<cite><a href="#ref_ARIA">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. This version incorporates changes
	       made in response to public comments received on the previous
	      version. A <a href="http://www.w3.org/WAI/PF/aria-practices/change-history">history
	      of changes to WAI-ARIA 1.0 Authoring Practices</a> is available. Refer
	      to the <a href="http://www.w3.org/WAI/PF/comments/actions?document_version_id%5B%5D=2&amp;document_version_id%5B%5D=7">summary
	      of actions made in response to comments on the previous two drafts</a> and
	      the <a href="http://www.w3.org/WAI/PF/comments/issue_disposition_report?document_version_id%5B%5D=2&amp;document_version_id%5B%5D=7">issue
	      disposition report for the previous  two drafts</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 PFWG 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>Start with the <a href="http://www.w3.org/WAI/PF/comments/instructions">instructions for commenting</a> page to submit comments (preferred), or send email to <a href="mailto:public-pfwg-comments@w3.org">public-pfwg-comments@w3.org</a> (<a href="http://lists.w3.org/Archives/Public/public-pfwg-comments/">comment archive</a>). Comments should be made by <strong>29 October 2010</strong>. In-progress updates to the document may be viewed in the <a href="/WAI/PF/aria-practices/">publicly visible editors' draft</a>.</p>
	
	<p>Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>
	<p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. The group does not expect this document to become a W3C Recommendation. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/32212/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p>
	<p>The disclosure obligations of the Participants of this group are described in the <a href="http://www.w3.org/WAI/PF/charter201006#patentpolicy">charter</a>.</p>
</div>
<div><a id="toc" name="toc"></a>
  <h2>Table of Contents</h2>
  <ol class="toc"><li>1. <a href="#intro">Introduction</a></li><li>2. <a href="#accessiblewidget">General Steps for Building an Accessible Widget with WAI-ARIA</a></li><li>3. <a href="#keyboard">Keyboard and Structural Navigation</a><ol class="toc"><li>3.1. <a href="#kbd_generalnav">Providing Keyboard Navigation for Widgets</a><ol class="toc"><li>3.1.1. <a href="#kbd_general_binding">WAI-ARIA Keyboard Bindings and Behaviors</a></li><li>3.1.2. <a href="#kbd_general_between">Keyboard Navigation between Widgets</a></li><li>3.1.3. <a href="#kbd_general_within">Keyboard Navigation within Widgets</a></li><li>3.1.4. <a href="#kbd_shortcuts">Keyboard Shortcuts for Widgets</a></li><li>3.1.5. <a href="#kbd_general_ex">Example Keyboard Operation: Radio Group/Radio</a></li><li>3.1.6. <a href="#kbd_general_other">Other Widget Authoring Practices</a></li></ol></li><li>3.2. <a href="#kbd_focus">Providing Keyboard Focus</a><ol class="toc"><li>3.2.1. <a href="#focus_tabindex">Using Tabindex to Manage Focus among Widgets</a></li><li>3.2.2. <a href="#focus_activedescendant">Using activedescendant to Manage Focus for Widget Children</a></li><li>3.2.3. <a href="#visualfocus">Managing Visual Focus with tabindex Alone</a></li><li>3.2.4. <a href="#scrollintoview">Managing Focus with Scroll</a></li><li>3.2.5. <a href="#dualfocus">Managing the Perception of a Dual Focus</a></li><li>3.2.6. <a href="#AuthDefKeys">Author-Defined Keyboard Short-Cuts or Mnemonics</a></li><li>3.2.7. <a href="#kbd_layout">Providing Navigable Structure within Web Pages</a></li></ol></li><li>3.3. <a href="#modal_dialog">Making a Dialog Modal</a><ol class="toc"><li>3.3.1. <a href="#trap_focus_div">Trapping Focus</a></li></ol></li></ol></li><li>4. <a href="#relations">Relationships</a><ol class="toc"><li>4.1. <a href="#relations_labeling">Labeling and Describing</a><ol class="toc"><li>4.1.1. <a href="#LabeledBy">Labeling</a></li><li>4.1.2. <a href="#Descriptions">Describing</a></li></ol></li><li>4.2. <a href="#relations_owning">Owning and Controlling</a><ol class="toc"><li>4.2.1. <a href="#relations_owns">The Owns Relationship</a></li><li>4.2.2. <a href="#relations_owns_reuse"> Using Owns with Reusable Content</a></li><li>4.2.3. <a href="#relations_controls">The Controls Relationship</a></li></ol></li><li>4.3. <a href="#relations_flowto">Changing the Reading Flow</a></li><li>4.4. <a href="#relations_haspopup">Popups and drop-downs</a></li></ol></li><li>5. <a href="#docmgt">Managing Dynamic Changes</a><ol class="toc"><li>5.1. <a href="#ContentPresChanges">Managing Content and Presentational Changes</a></li><li>5.2. <a href="#LiveRegions">Implementing Live Regions</a><ol class="toc"><li>5.2.1. <a href="#liveprops">Live Region Properties and How to Use Them</a></li></ol></li><li>5.3. <a href="#chobet">Choosing Between Special Case Live Regions</a></li></ol></li><li>6. <a href="#ariaform">Form Properties</a></li><li>7. <a href="#math">Math</a></li><li>8. <a href="#dragdrop">Drag-and-Drop Support</a></li><li>9. <a href="#aria-write">States and Properties Modified by an External Assistive Technology</a></li><li>10. <a href="#aria_ex">Design Patterns</a></li><li>11. <a href="#reuse_comp_lib">Reusable Component Libraries</a></li><li>12. <a href="#appendices">Appendices</a><ol class="toc"><li>12.1. <a href="#references">References</a></li><li>12.2. <a href="#acknowledgements">Acknowledgments</a><ol class="toc"><li>12.2.1. <a href="#ack_group">Participants in the PFWG at the time of publication</a></li><li>12.2.2. <a href="#ack_others">Other previously active PFWG participants and other contributors to the Accessible Rich Internet Applications specification</a></li><li>12.2.3. <a href="#ack_funders">Enabling funders</a></li></ol></li></ol></li></ol>
</div>
<div class="section" id="intro">
  <h2><span class="tocnum">1. </span>  Introduction</h2>
  <p>This section is <em>informative.</em></p>
  <p>The WAI-ARIA Authoring Practices Guide is intended to provide readers with an understanding of how to use WAI-ARIA to create an accessible Rich Internet Application. As explained in the <a href="http://www.w3.org/TR/2010/WD-wai-aria-primer-20100916/">WAI-ARIA Primer</a>, accessibility deficiencies in today's markup render rich internet applications  unusable by people who use assistive technologies (AT) or who rely on keyboard navigation. The W3C Web Accessibility Initiative's (WAI) Protocols and Formats working group (PFWG) plans to address these deficiencies through several W3C standards efforts, with a focus on the WAI-ARIA specifications. </p>
  <p>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>. The WAI-ARIA Authoring Practices Guide is part of a set of resources that support the WAI-ARIA specification. The practices describe recommended usage patterns for web content developers, and the <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-primer-20100916/">WAI-ARIA Primer</a></cite> [<cite><a href="#ref_ARIA-PRIMER">ARIA-PRIMER</a></cite>] provides a basic introduction to the concepts behind and reason for WAI-ARIA. The WAI-ARIA suite fills gaps identified by the <a href="http://www.w3.org/TR/2008/WD-wai-aria-roadmap-20080204/">Roadmap for Accessible Rich Internet Applications (<acronym title="Web Accessibility Initiative">WAI</acronym>-<cite><acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym></cite> Roadmap)</a> [<cite><a href="#ref_ARIA-ROADMAP">ARIA-ROADMAP</a></cite>].  These documents serve as important places of clarification where topics appear to be unclear.</p>
  <p>With the conceptual basis provided in the WAI-ARIA Primer, you should have a good understanding of how WAI-ARIA provides for interoperability with assistive technologies and support for a more usable, accessible experience. This guide begins  by providing some general steps for building an accessible widget  using WAI-ARIA, script, and CSS.  It then extends your knowledge of WAI-ARIA with detailed guidance on how to make rich internet applications keyboard accessible. Next, the scope widens to include the full application, addressing necessary layout and structural semantics within the Web page. These semantics are critical to enable assistive technologies to provide a usable experience when processing rich internet applications with rich documents on the same page. It includes guidance on dynamic document management; use of WAI-ARIA Form properties; WAI-ARIA Drag and Drop; and then the creation of WAI-ARIA-enabled alerts and dialogs. The  appendix provides substantial reference information including code samples for developers of user agents, assistive technologies, and Web pages. </p>
  <p class="note">WAI-ARIA markup is currently not included in (X)HTML. The W3C WAI PF working   group will be creating DTDs for XHTML 1.0 and HTML 4.01 for those wishing to   validate their markup with WAI-ARIA embedded into these host languages. </p>
</div>
<div class="section" id="accessiblewidget">
  <h2><span class="tocnum">2. </span>  General Steps for Building an Accessible Widget with WAI-ARIA</h2>
  <p>At this point you should have a basic understanding of how WAI-ARIA is used to support interoperability with assistive technologies. If you are not reusing a WAI-ARIA-enabled widget library and wish to create your own the following steps will guide you through the thought process for creating an accessible widget using WAI-ARIA. </p>
  <ol><li>
      <p><strong>Pick the widget type (role) from the WAI-ARIA taxonomy</strong></p>
      <p>WAI-ARIA provides a <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles.html">role taxonomy</a></cite> ([<cite><a href="#ref_ARIA">ARIA</a></cite>], Section 3.4) constituting  the most common UI component types. Choose the role type from the provided table. If your desire was to create a toolbar set the role to toolbar:</p>
      <pre class="example" xml:space="preserve"><span class="tag">&lt;div role=<span class="str">"toolbar"</span>&gt;</span></pre>
    </li><li><strong>From the role, get the list of supported states and properties</strong>
      <p> Once you have chosen the role of your widget, consult the <cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/">WAI-ARIA specification</a></cite> [<cite><a href="#ref_ARIA">ARIA</a></cite>] for an in-depth definition for the role to find the supported states, properties, and other attributes. For example, the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#toolbar"><code>toolbar</code></a> role definition includes:</p>
      <dl><dt>parent role</dt><dd>In the taxonomy the widget you selected inherits states and properties from this role. In the case of a toolbar you will see that a toolbar is a subclass of a group. This makes sense given that a toolbar is a collection of commonly used functions.</dd><dt>related concept</dt><dd>This is really more informative to state what other concepts are similar to this role. These may exist in different host languages outside WAI-ARIA. 
          The keyboard model 
          for the control should emulate that of the related concept control. </dd><dt>supported states and properties</dt><dd>These are unique states and properties that this widget supports and that were not inherited from its ancestors in the taxonomy. In the case of a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#toolbar"><code>toolbar</code></a> there are no such states or properties. However, in the case of a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listbox"><code>listbox</code></a>, you may choose to set the property of <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-multiselectable"><code>aria-multiselectable</code></a> to true if you were to have more than one item in the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listitem"><code>listitem</code></a> selected at a time.  This indicates to the assistive technology that the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listbox"><code>listbox</code></a> manages a collection of selectable options.</dd><dt>inherited states and properties</dt><dd>These are all the states and properties which are inherited from the roles's ancestors and which you may use. </dd><dt>global states and properties</dt><dd>These are states and properties which apply to all host language components regardless of whether a role is set or not. You may use these as well. </dd></dl>
      <p>Once you have chosen the states and properties that apply to your widget you must set those properties you will use to set their initial values. Note: You do not need to use all the states and properties available for your role. In our case we shall use:</p>
      <pre class="example" xml:space="preserve"><span class="tag">&lt;div role=<span class="str">"toolbar"</span> tabindex=<span class="str">"0"</span> id=<span class="str">"customToolbar"</span> 
      onkeydown=<span class="str">"return optionKeyEvent(event);"</span>
      onkeypress=<span class="str">"return optionKeyEvent(event);"</span>
      onblur=<span class="str">"hideFocus()"</span>
      onfocus=<span class="str">"showFocus()"</span>
      &gt;</span> 
      <span class="tag">&lt;img src=<span class="str">"img/btn1.gif"</span> tabindex=<span class="str">"0"</span> title=<span class="str">"Home"</span> 
           role=<span class="str">"button"</span> id=<span class="str">"b1"</span> alt=<span class="str">"Home"</span> 
           onClick=<span class="str">"updateText('Home was invoked');"</span>&gt;</span>
      <span class="tag">&lt;img src=<span class="str">"img/btn2.gif"</span> tabindex=<span class="str">"-1"</span> title=<span class="str">"Refresh"</span> 
           role=<span class="str">"button"</span> id=<span class="str">"b2"</span> alt=<span class="str">"Refresh"</span> 
           onClick=<span class="str">"updateText('Refresh was invoked');"</span>&gt;</span>
     <span class="tag">&lt;img src=<span class="str">"img/btn3.gif"</span> tabindex=<span class="str">"-1"</span> title=<span class="str">"Help"</span> 
           role=<span class="str">"button"</span> id=<span class="str">"b3"</span> alt=<span class="str">"Help"</span> 
           onClick=<span class="str">"updateText('Help was invoked');"</span>&gt;</span> 
<span class="tag">&lt;/div&gt;</span>  
</pre>
      <p> By avoiding <code>tabindex</code> on the toolbar and setting <code>tabindex=0</code> on the first button, but <code>tabindex=-1</code> on the others, we have specified that the first button in the toolbar will receive focus in the document order. It is then necessary to use script to change the focus amongst the buttons from there.      </p>
      <div class="note">
        <p>Important: When embedding WAI-ARIA markup in (X) HTML, all WAI-ARIA states and properties must be preceded with the characters <code>aria-</code> with the exception of the <code>role</code> and <code>tabindex</code> attributes. Otherwise, the user agent will not map the WAI-ARIA information, resulting in it not being  recognized by assistive technologies. </p>
        <p>When embedding WAI-ARIA into other host languages, <code>tabindex</code> does not carry over. The WAI-ARIA <code>tabindex</code> extensions are specific to (X)HTML to repair deficiencies in keyboard support. </p>
      </div>
    </li><li><strong>Establish the widget structure in the markup (parent/child)</strong>
      <p>Assistive technologies are very dependent on the structure of widgets as well as general document structure. Structure provides context to the user. A toolbar is a collection of common functions made available to the user. Therefore, all functions you would like in the toolbar must  be contained within it. This can be determined by using the <cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/">Document Object Model</a></cite> [<cite><a href="#ref_DOM">DOM</a></cite>] tree structure created by the browser when parsing the host language. By using the parent child relationship of the DOM, an assistive technology can determine all the related toolbar widgets associated with the toolbar. The toolbar widgets would be DOM children of the "toolbar" container. For our purposes we will define three image buttons for cut, copy, and paste.</p>
      <pre class="example" xml:space="preserve"><span class="tag">&lt;div role=<span class="str">"toolbar"</span> tabindex=<span class="str">"0"</span> aria-activedescendant=<span class="str">"button1"</span>&gt;</span>
  <span class="tag">&lt;img src=<span class="str">"buttoncut.png"</span> alt=<span class="str">"cut"</span> id=<span class="str">"button1"</span>&gt;</span>
  <span class="tag">&lt;img src=<span class="str">"buttoncopy.png"</span> alt=<span class="str">"copy"</span> id=<span class="str">"button1"</span>&gt;</span>
  <span class="tag">&lt;img src=<span class="str">"buttonpaste.png"</span> alt=<span class="str">"paste"</span> id=<span class="str">"button1"</span>&gt;</span>
<span class="tag">&lt;/div&gt;</span>  </pre>
    </li><li><strong>Repeat steps 1-3 for the children of the parent</strong>
      <p>We now need to assign the roles and states for each of the children. However, we shall save the detailed navigation for step 5.</p>
      <pre class="example" xml:space="preserve"><span class="tag">&lt;div role=<span class="str">"toolbar"</span> tabindex=<span class="str">"0"</span> aria-activedescendant=<span class="str">"button1"</span>&gt;</span>
  <span class="tag">&lt;img src=<span class="str">"buttoncut.png"</span> alt=<span class="str">"cut"</span> role=<span class="str">"button"</span> id=<span class="str">"button1"</span>&gt;</span>
  <span class="tag">&lt;img src=<span class="str">"buttoncopy.png"</span> alt=<span class="str">"copy"</span> role=<span class="str">"button"</span> id=<span class="str">"button2"</span>&gt;</span>
  <span class="tag">&lt;img src=<span class="str">"buttonpaste.png"</span> alt=<span class="str">"paste"</span> role=<span class="str">"button"</span> id=<span class="str">"button3"</span>&gt;</span>
<span class="tag">&lt;/div&gt;</span>
</pre>
      <p>The process of setting roles and states may be a recursive procedure if the children themselves have children, such as in the case of an expandable/collapsible <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tree"><code>tree</code></a> widget.</p>
    </li><li>
      <p><strong>Establish keyboard navigation of the widget and plan for how it will be navigated to within the document</strong></p>
    	<p>It is very important that  your widget be keyboard accessible. In fact, there must be a keyboard equivalent for every mouse operation. Where possible you should refer to the <a href="#aria_ex">WAI-ARIA examples</a> in this guide for tips on how to implement keyboard navigation for your widget. If you find that an example is not provided, you should follow standard keyboard bindings for UI components such as those used for the Java Foundation Classes for Windows 95/NT.</p>
      <p>For our toolbar, we have chosen to have the toolbar manage the focus for its children and through the use of the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> property. We have also chosen to have the toolbar receive focus based on the tab order by using <code>tabindex</code>. In order to use <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a>, each focusable descendant must have an assigned ID. </p>
      <pre class="example" xml:space="preserve"> <span class="tag">&lt;head&gt;</span>
 <span class="tag">&lt;script&gt;</span>
    ... 
    function optionKeyEvent(event)
      {
      var tb = event.target;
      var buttonid; 
  
      DOM_VK_ENTER = 13;
      // Partial sample code for processing arrow keys

      if (event.type == "keydown") {
         if (event.altKey) {
           return true;  // Browser should use this, the menu view doesn't need alt-modified keys
         }
         // XXX Implement circular keyboard navigation within the toolbar buttons
  
         if (event.keyCode == DOM_VK_ENTER) {
           ExecuteButtonAction(getCurrentButtonID()); // This is an author defined function
         }
         else if (event.keyCode == event.DOM_VK_RIGHT) {
           // Change the active toolbar button to the one to the right (circular) by 
           var buttonid = getNextButtonID();   // This is an author defined function
           tb.setAttribute("aria-activedescendant", buttonid); 
         }
         else if (event.keyCode == event.DOM_VK_LEFT) {
            // Change the active toolbar button to the one to the left (circular) by 
            var buttonid = getPrevButtonID();  // This is an author defined function
            tb.setAttribute("aria-activedescendant", buttonid); 
         } 
         else {
            return true;
         }
         return false;
      }
      else if (event.type == "keypress") {
        ...
      }
    }  
<span class="tag">&lt;/script&gt;</span>

<span class="tag">&lt;div role=<span class="str">"toolbar"</span> tabindex=<span class="str">"0"</span> aria-activedescendant=<span class="str">"button1"</span> id=<span class="str">"tb1"</span> 
  onkeydown=<span class="str">"return optionKeyEvent(event);"</span>
  onkeypress=<span class="str">"return optionKeyEvent(event);"</span>&gt;</span>
  <span class="tag">&lt;img src=<span class="str">"buttoncut.png"</span> alt=<span class="str">"cut"</span> role=<span class="str">"button"</span> id=<span class="str">"button1"</span>&gt;</span>
  <span class="tag">&lt;img src=<span class="str">"buttoncopy.png"</span> alt=<span class="str">"copy"</span> role=<span class="str">"button"</span> id=<span class="str">"button2"</span>&gt;</span>
  <span class="tag">&lt;img src=<span class="str">"buttonpaste.png"</span> alt=<span class="str">"paste"</span> role=<span class="str">"button"</span> id=<span class="str">"button3"</span>&gt;</span>
<span class="tag">&lt;/div&gt;</span></pre>
      <p>The details of implementing keyboard navigation are described in <a href="#keyboard">Keyboard and Structural Navigation</a> section of this document.</p>
      <p class="note">Note: You must also show the visual focus for each element that has focus. </p>
    </li><li>
      <p><strong>Apply and  manage needed WAI-ARIA states in response to user input events</strong></p>
      <p>Similar to the processing of <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> in Step 5, as author you must set any additional WAI-ARIA states and properties on document elements.</p>
    </li><li>
      <p><strong>Synchronize the visual UI with accessibility states and properties for supporting user agents</strong></p>
      
      <p>You should consider binding  user interface changes directly to changes in WAI-ARIA states and properties, such as through  the use of <a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/selector.html#attribute-selectors">CSS attribute selectors</a>. For example, the setting of the <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-selected"><code>aria-selected</code> (state)</a> state may change the background of a selected <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treeitem"><code>treeitem</code></a> in a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tree"><code>tree</code></a>. This may also be done with JavaScript.</p>
      <pre class="example" xml:space="preserve">
.treeitem[role="treeitem"][aria-selected="true"] {color: white; background-color: #222222;}

.treeitem[role="treeitem"][aria-selected="false"] {color: white; background-color: beige;}        </pre>
      <p>Authors should be aware that CSS attribute selectors are not supported in some browsers, such as Internet Explorer 6. A consistent way to apply styling to reflect WAI-ARIA semantics would be to assign an element a class name based on the WAI-ARIA attribute being set using script as shown here:</p>
      <pre class="example" xml:space="preserve">function setSelectedOption(menuItem)
     {
        if (menuItem.getAttribute("role") != "menuitem") {
           return;
        }
        var menu = getMenu(menuItem);
        var oldMenuItem = getSelectedOption(menu);
        
        // Set class so that we show selection appearance
        oldMenuItem.className="unselected";
        menu.setAttribute("aria-activedescendant", menuItem.id);
        menuItem.className= "selected";
      }</pre>
    </li><li> <strong>Showing and Hiding Sections in a Widget</strong>
      <p> The proper synchronization of showing and hiding sections in a widget with the WAI-ARIA display state is also critical. Some platform accessibility <abbr title="Application Programming Interfaces">APIs</abbr> provide events for applications to notify the assistive technology when pop-ups such as menus, alerts, and dialogs come into view or go away. Rich Internet applications can assist browsers which support these conventions by: </p>
      <ol><li>
          <p> Creating an entire section and then insert it into the <cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/">Document Object Model</a></cite> [<cite><a href="#ref_DOM">DOM</a></cite>],  as a subtree of the parent element activated to show the pop-up,  and then removing the section from the inserted area when  the pop-up goes away.</p>
          <p>OR</p>
        </li><li>
          <p>Using the following style sheet properties to show and hide document sections being used to represent the pop-up items, menus or dialogs:</p>
          <ul><li><code>display:block</code></li><li><code>display:none</code></li><li><code>visibility:visible</code></li><li><code>visibility:hidden</code></li></ul>
          <p>By monitoring these behaviors a user agent may use this information to notify assistive technology that the pop-up has occurred by generating the appropriate accessibility <abbr title="Application Programming Interface">API</abbr> event. </p>
        </li></ol>
      <p>Some assistive technologies may use the DOM directly to determine these when pop-up occurs. In this case, the first mechanism of writing a section to the DOM would work using the DOM events as demonstrated here. </p>
      <pre class="example" xml:space="preserve">
	  // create new table row with table cell and div
	  var newTr = document.createElement('TR');
	  var newTd = document.createElement('TD');
	  var newDiv = document.createElement('DIV');
	  newTr.appendChild(newTd);
	  newTd.appendChild(newDiv);
	  
	  
	  //insert this new table row before the Node selected
	  var container = theNode.parentNode;
	  container.insertBefore(newTr, theNode);
	  
	  //remove theNode selected
	  container.removeChild(theNode);"</pre>
      <p>However, if you are using CSS to show and hide sections of the DOM (2) it is essential that you set the corresponding WAI-ARIA <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-hidden"><code>aria-hidden</code> (state)</a> property to indicate that the section is visible or hidden and synchronize it with your CSS styling as shown here: </p>
      <pre class="example" xml:space="preserve">[aria-hidden=true] {visibility: hidden;}

...

<span class="tag">&lt;div role=<span class="str">"button"</span> aria-haspopup=<span class="str">"true"</span> aria-owns=<span class="str">"mypopupmenu"</span>&gt;</span>
<span class="tag">&lt;div role=<span class="str">"menu"</span> aria-hidden=<span class="str">"true"</span> id=<span class="str">"mypopupmenu"</span>&gt;</span>...<span class="tag">&lt;/div&gt;</span></pre>
    </li><li><strong>Support basic accessibility, such as alternative text on images</strong>
      <p>When an image is used to represent information within a component, such as  image buttons, you need to set the alternative text on those images. This is then mapped by the user agent to the accessible name in the platform accessibility API. Using our example:</p>
      <pre class="example" xml:space="preserve"><span class="tag">&lt;div role=<span class="str">"toolbar"</span> tabindex=<span class="str">"0"</span> aria-activedescendant=<span class="str">"button1"</span> id=<span class="str">"tb1"</span> 
     onkeydown=<span class="str">"return optionKeyEvent(event);"</span>      
     onkeypress=<span class="str">"return optionKeyEvent(event);"</span>&gt;</span>    
   <span class="tag">&lt;img src=<span class="str">"buttoncut"</span> role=<span class="str">"button"</span> id=<span class="str">"button1"</span> alt=<span class="str">"cut"</span>&gt;</span>
   <span class="tag">&lt;img src=<span class="str">"buttoncopy"</span> role=<span class="str">"button"</span> id=<span class="str">"button2"</span> alt=<span class="str">"copy"</span>&gt;</span>
   <span class="tag">&lt;img src=<span class="str">"buttonpaste"</span> role=<span class="str">"button"</span> id=<span class="str">"button3"</span> alt=<span class="str">"paste"</span>&gt;</span>      
<span class="tag">&lt;/div&gt;</span></pre>
    </li><li><strong>Establish WAI-ARIA relationships between this widget and others</strong>
      <p>Once you have made the basic widget accessible you may then need to establish its relationship to other widgets. Examples of this are <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a>, <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a>, <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-flowto"><code>aria-flowto</code></a>. The details of using these relationships are described in the <a href="#relations">Relationships</a> section of this document. </p>
      <p>Other relationships which should be considered are more declarative and provide context to the widget within a set. For these, <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-level"><code>aria-level</code></a>, <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-posinset"><code>aria-posinset</code></a>, and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-setsize"><code>aria-setsize</code></a> are provided. If you structure your Document Object Model appropriately so that the user agent can determine this information from it using the DOM hierarchy directly, you do not need to set these properties. There are, however, situations in rich internet applications where all the elements in a container are not in the DOM at one time, such as when you can only render the ten of fifty items in a subtree. In this case the user agent cannot determine the number of tree items (<a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-setsize"><code>aria-setsize</code></a>) for the position in the set (<a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-posinset"><code>aria-posinset</code></a>), and potentially the tree depth (<a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-level"><code>aria-level</code></a>) from the DOM. In these situations you will need to provide these WAI-ARIA properties.</p>
    </li><li>
      <p><strong>Review widget to ensure that you have not hard coded sizes</strong></p>
      <p>The ability for applications to respond to system font settings is a requirement. Most user agents are designed to meet this requirement. This also means your Web application running within your browser is impacted when the user agent changes the font sizes to meet the need. If you have hard coded your font size in pixels  an increase in system fonts will not be reflected in your Web application. You must also not hard code the size of your widgets in pixels either. If the fonts are scalable, but the widget they are encapsulated in is not, then the text could flow outside your widget. </p>
<p>Follow these rules to allow your application to respond to system font settings:</p>
<ul><li>Establish a base set of font sizes used in widgets based on percentage of the container element font size.</li><li>Use <abbr title="Cascading Style Sheets">CSS</abbr> width, borders, margin, padding, background, and positioning properties to specify the 		graphical rendering of widgets and their sub-components, use percentage units or em units to specify widths of widget components (An em is a  the font unit of measure between the top and bottom of an upper case letter M.). Border      widths, padding, and margins can use <abbr title="pixel">PX</abbr> units.</li><li>Use scripting for run time CSS positioning of widget sub-components in relation to other sub components.</li><li>Make sure all widgets use consistent height and width units of measure.</li></ul>
<p>
Percentages are the most reliable way to consistently specify proportional text sizes in widgets. The use of percentages and em should be used for specifying widths of a widget and the widget sub components. The use of percentages for text size and percentages and em units for widths support browser zoom capabilities to make widgets larger or smaller.

Pixels can be used for specifying line widths, padding and margins.</p>
      <p class="note"> <em>Important: Most browsers today have a zoom feature which allow the user to magnify the entire Web page. Most legislation today requires that your application respond to system font and color settings and therefore you will want to consider the fact the system settings could adversely affect your Web page should you decide to hard code pixel sizes.</em> </p>
    </li><li> <strong>Test with User agent, Assistive Technology, and People with disabilities</strong>
      <p>To ensure you have set your WAI-ARIA semantics correctly, test your application with your user agent, an assistive technology, and a person with disability. Example assistive technologies are screen readers and screen magnifiers. Ensure that your user agent is designed to support WAI-ARIA and their your assistive technology is designed to support WAI-ARIA  in the selected user agent.</p>
      <p>Finding people with disabilities to do testing may be difficult but many companies employ people with disabilities, including your customers, and you should reach out to them to ask for help. Other places to look are advocacy groups like the National Federation of the Blind or your local schools for the blind, reading and learning centers, and so on.  The people you reach out to may someday need to use  what you produce.</p>
    </li></ol>
</div>
<div class="section" id="keyboard">
  <h2><span class="tocnum">3. </span>  Keyboard and Structural Navigation</h2>
  <p>Providing an effective navigation experience to the user is critical for usability. This section starts with guidance on how to provide effective keyboard navigation for widgets in a Rich Internet Application environment. This includes a discussion on how to manage keyboard focus and the specifics on providing keyboard navigation for tooltips. This is is followed by a broader discussion on how to convey structural semantics for the entire Web page. These semantics help  an assistive technology  provide  additional navigation, increase user productivity, and render the page in an alternative formats. This rendering may be in different forms, including but not limited to speech, page restructuring, and alternative input solutions.</p>
  <div class="section" id="kbd_generalnav">
    <h3><span class="tocnum">3.1. </span> Providing Keyboard Navigation for Widgets</h3>
    <div class="section" id="kbd_general_binding">
      <h4><span class="tocnum">3.1.1. </span> WAI-ARIA Keyboard Bindings and Behaviors</h4>
      <p> Essential to accessible Web 2.0 widgets is keyboard support to provide full operation and functionality of a widget through keyboard-only events. Unlike traditional HTML form controls, Web 2.0 widgets, typically, have no inherent keyboard support. The developer must enable keyboard support for the widgets they create or use widget libraries with keyboard support. The model for keyboard support for Web 2.0 widgets are graphical user interface (GUI) operating systems like Microsoft Windows, Mac OS X; and other desktop operating systems like GNOME and GTK. Basic accessibility requirements for keyboard focus include: </p>
      <ul><li>Support users who cannot use pointing devices due to physical or visual impairment to access the full functionality of the Web application. </li><li>All major software and Web accessibility guidelines for people with disabilities require keyboard-only operation of the interface for accessibility. </li><li>Communicate accessibility information to assistive technologies on the type of widget and its associated state and properties. </li></ul>
      <p>For example, if a screen reader user hears a tree announced, they know that pressing the right arrow key will expand  a node. Similarly, when they hear a grid announced, they know they can use their screen reader's table reading commands. </p>
    </div>
    <div class="section" id="kbd_general_between">
      <h4><span class="tocnum">3.1.2. </span>  Keyboard Navigation between Widgets</h4>
      <p> The <code>tabindex</code> attribute enables focus to be moved via keyboard to HTML elements. For standard <a href="http://www.w3.org/TR/html401/">HTML 4.01</a>, tabindex was limited to form and anchor elements. For WAI-ARIA, the <code>tabindex</code> attribute is now applicable to all renderable HTML elements with additional functionality designed to help the author produce keyboard accessible  Web 2.0 widgets. </p>
      <ul><li><kbd>Tab</kbd> and <kbd>Shift+Tab</kbd> key move focus among widgets and standard HTML controls. </li><li>Widgets with tabindex=0 will be added to the tab sequence based on document order </li><li>Widgets with tabindex&gt;0 will be added to the tab sequence based on the TABINDEX value </li><li>Widgets with tabindex&lt;0 will not be added to the tab sequence but are enabled to receive keyboard focus. </li></ul>
      <p>Once a widget has keyboard focus, arrow keys, <kbd>Space</kbd>, Enter key, or other keyboard commands can be used to navigate the options of the widget, change its state, or trigger an application function associated with the widget. </p>
    </div>
    <div class="section" id="kbd_general_within">
      <h4><span class="tocnum">3.1.3. </span>  Keyboard Navigation within Widgets</h4>
      <p> Each element that receives keyboard focus needs to have a <code>tabindex</code> attribute set to its current active descendant element and itself if an active descendant does not exist. The element with keyboard focus is essential because it communicates information about the widget to assistive technologies like screen readers and magnifiers through operating specific accessibility APIs like Microsoft Active Accessibility (MSAA), the Apple AX APIs, and the ATK Accessibility Toolkit. The TAB key moves keyboard focus to the widget, and other keys operate the features of the widget, typically cursor keys, Enter key and <kbd>Space</kbd>. The actual keys are up to the developer, but best practices recommend using the same key bindings that are used to control similar widgets in common GUI operating systems like Microsoft Windows, Mac OS X and other desktop operating systems like GNOME and GTK. </p>
      <p> JavaScript can use either the focus() method to move focus to the appropriate element in the widget, or it can use a WAI-ARIA property called <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> on the actual widget container to indicate which element in the widget must have focus. The following procedure should be followed when focus is completely dependent on the use of tabindex to provide focus in a widget:</p>
      <ul><li> Set tabindex="0" to the current active descendant in the widget while setting tabindex="-1" on all the other child elements of the widget</li><li>As the user navigates (e.g. arrows) away from an item, the old item gets a tabindex="-1" and the new item gets tabindex="0".</li><li>Use the javascript method to set focus, using its JavaScript focus() method, on the item whose tabindex="-1"</li></ul>
      <p><a id="roving" name="roving"></a>This procedure creates a <em>roving</em> tabindex. If you  tab away and the tab back to the widget, the same last active descendant becomes active again. This relieves the author from having to compute and set the focus to the last activedescendant. </p>
      <p>Conversely, if you use the WAI-ARI <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> property things get a lot easier: </p>
      <ul><li>Set tabindex="0" on the element which is the composite widget, and set its activedescendant property to the id of the child you wish to be active,</li><li>As the user navigates (e.g. arrows) away from an item in the widget, refresh the activedescendant property on the containing widget to the id of the new active descendant child. </li></ul>
      <p>The browser will then be responsible for managing focus changes for you. For greater detail, see <a href="#focus_tabindex">Using Tabindex to Manage Focus Among Widgets</a>. In both scenarios the author must indicate through styling and/or markup which element in the widget has focus or is "active." </p>
    </div>
    <div class="section" id="kbd_shortcuts">
    	<h4><span class="tocnum">3.1.4. </span> Keyboard Shortcuts for Widgets</h4>
    	<p>It is useful to provide keyboard access to widgets, to focus a widget directly and to activate the features within the widget. These may be "mnemonics" that use a letter from the label of the control, as well as other special keys that perform familiar operations on the system. When providing non-standard key commands, document them so the user knows how to use them.</p>
    	<p>When localizing the user interface, it may be necessary to localize keyboard mnemonics as well in order to keep them apparent. Be sure not to introduce key conflicts when doing this, and ensure that the correct key commands remain apparent to the user.</p>
    </div>
    <div class="section" id="kbd_general_ex">
      <h4><span class="tocnum">3.1.5. </span>  Example Keyboard Operation: Radio Group/Radio </h4>
      <p> See working <a href="http://test.cita.uiuc.edu/aria/radio/" title="CITA Radio Button Examples">Radio button examples</a> from the University of Illinois.</p>
      <table summary="two-column table with one heading row where column one lists a key and column two describes the response to that key press in a radio button group"><caption>
        Key Bindings for Radio Group Behavior - Example
        </caption><tr><th rowspan="1" colspan="1">Key</th><th rowspan="1" colspan="1">Description of Radio Group Behavior</th></tr><tr><td rowspan="1" colspan="1">Tab Key</td><td rowspan="1" colspan="1"> If no radio button is checked, focus moves to the first radio button in the group, but the radio button remains unchecked. If one radio button is checked, focus moves to the checked radio button. If SHIFT+TAB is pressed, focus moves to the last radio button in the group, but the radio button remains unchecked. </td></tr><tr><td rowspan="1" colspan="1">Space Bar</td><td rowspan="1" colspan="1"> Checks the radio button with keyboard focus (this is a special case when using tab and no radio buttons have been marked as checked). </td></tr><tr><td rowspan="1" colspan="1">Down Arrow</td><td rowspan="1" colspan="1">If no button is checked, check the first radio button. If the last radio button is checked, check the first radio button. Otherwise, move the check from the current radio button to the next radio button. </td></tr><tr><td rowspan="1" colspan="1">Up Arrow</td><td rowspan="1" colspan="1">If no button is checked, check the last radio button. If the first radio button is checked, check the last radio button. Otherwise, move the check from the current radio button to the previous radio button. </td></tr></table>
    	<p>In this Radio Group example, the <code>tabindex</code> of the first and last radio button elements has a <code>tabindex="0"</code> (assuming none of the radio buttons is checked), the remaining radio elements have <code>tabindex="-1"</code>.  As soon as the first or the last radio button receives focus it changes the <code>tabindex</code> value of the other radio button to -1.  If none of the radio buttons is selected the and the keyboard focus leaves the group the first and the last radio buttons have their <code>tabindex</code> values set to 0. </p>
    </div>
    <div class="section" id="kbd_general_other">
      <h4><span class="tocnum">3.1.6. </span>  Other Widget Authoring Practices</h4>
      <p>The <a href="#aria_ex_widget">Common Widget Design Patterns</a> section of this document contains best  practices, such as keyboard navigation, for creating common widgets found on the Web. This section contains miscellaneous authoring practices that you should also consider.</p>
      <div class="section" id="kbd_general_valuenow">
      <h5><span class="tocnum">3.1.6.1. </span> Maintain a valid format for aria-valuenow</h5>
<p>
It is essential that application vendors maintain a valid format for
<a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuenow"><code>aria-valuenow</code></a>, and aria-valuenow should
accurately represent the value of the widget.The value must be within range of <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuemin"><code>aria-valuemin</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuemin"><code>aria-valuemin</code></a>, where the value of aria-valuemin is less than or equal to the value of aria-valuemax, throughout the life cycle of your widget. If aria-valuemin is not less than or equal to the value of aria-valuemax, or if the aria-valuemax is indeterminate, this creates an error condition that will be handled by 
the assistive technology, resulting in undesirable results. Should an alternative text
  equivalent be needed to properly represent the aria-valuenow, such as a day
  of the week, then you should accompany the aria-valuenow with an appropriate
  aria-valuetext equivalent such as in this example: </p>
<pre xml:space="preserve">
<span class="tag">&lt;div role=<span class="str">"slider"</span> aria-valuenow=<span class="str">"1"</span> 
	aria-valuemin=<span class="str">"1"</span> aria-valuemax=<span class="str">"7"</span>
	aria-valuetext=<span class="str">"Sunday"</span>&gt;</span>
</pre>
<p>
Here the values 1 through 7 represent the days of the week and
  aria-valuenow of 1 is equivalent to the first day of the week or Sunday.When aria-valuetext is made available aria-valuenow should also be treated as an   index which is 1 based. </p>
</div>
    </div>
  </div>
  <div class="section" id="kbd_focus">
    <h3><span class="tocnum">3.2. </span>  Providing Keyboard Focus</h3>
    <p>One way to provide keyboard support in (X)HTML is with form and list elements that accept keyboard focus by default. With the <kbd>Tab</kbd> key, the user can navigate to these types of elements. However, when building sophisticated widgets, it's necessary to be able to control keyboard navigation exactly. Authors may require or prefer to use host language elements that do not have built-in keyboard navigation features. For example, the author may wish to provide keyboard navigation without altering the tab order. Navigating within large composite widgets such as tree views, menubars, and spreadsheets can be very tedious and is inconsistent with what users are familiar with in their desktop counterparts. The solution is to provide full keyboard support using the arrow keys to provide more intuitive navigation within the widget, while allowing Tab and <kbd>Shift</kbd>+Tab to move focus out of the widget to the next place in the tab order. </p>
<p> A tenet of keyboard accessibility is reliable, persistent indication of focus. The author is responsible, in the scripts, for maintaining visual and programmatic focus and observing accessible behavior rules. Screen readers and keyboard-only users rely on focus to operate rich internet applications with the keyboard. </p>
    <div class="section" id="focus_tabindex">
      <h4><span class="tocnum">3.2.1. </span>  Using Tabindex to Manage Focus among Widgets</h4>
      <p>One requirement for supporting the keyboard is to allow focus to be set to any element. The <a href="http://www.w3.org/TR/html401/interact/forms.html#adef-tabindex" title="HTML4 tabindex attribute ">tabindex</a> attribute can be used to include additional elements in the tab order and to set programmatic focus to them. Originally implemented in Internet Explorer 5, the feature has been extended to Opera, Firefox, and Mozilla. The following table outlines the use of the tabindex attribute: </p>
      <div>
        <table border="1" cellspacing="0" summary="three-column table with one heading row where column one lists the Tabindex attribute, column two indicates how the element takes focus, and column three describes the tab navigation"><caption>
          Use of the Tabindex Attribute
          </caption><tbody><tr><th rowspan="1" colspan="1">Tabindex Attribute</th><th rowspan="1" colspan="1">Focusable with mouse or JavaScript via element.focus()</th><th rowspan="1" colspan="1">Tab Navigation</th></tr><tr><td rowspan="1" colspan="1"><p>not present</p></td><td rowspan="1" colspan="1">Follows default behavior of element (only form controls and anchors can receive focus.)</td><td rowspan="1" colspan="1">Follows default behavior of element</td></tr><tr><td rowspan="1" colspan="1"><p>zero - tabindex="0"</p></td><td rowspan="1" colspan="1">yes</td><td rowspan="1" colspan="1">In tab order relative to element's position in document</td></tr><tr><td rowspan="1" colspan="1"><p>Positive - tabindex="X" (where X is a positive integer between 1 and 32768)</p></td><td rowspan="1" colspan="1">yes</td><td rowspan="1" colspan="1">Tabindex value directly specifies where this element is positioned in the tab order.</td></tr><tr><td rowspan="1" colspan="1"><p>Negative - tabindex="-1"</p></td><td rowspan="1" colspan="1">yes</td><td rowspan="1" colspan="1">No, author must focus it with element.focus() as a result of arrow or other key press</td></tr></tbody></table>
      </div>
      <p>Setting a tabindex value of -1 to an element enables the element to receive focus via JavaScript using the element.focus() method. This method is used to enable arrow key navigation to elements. Each element that can be navigated to via arrow keys must have a tabindex of -1 to enable it to receive focus. Here are just a few additional tips  to help you with managing keyboard focus:</p>
      <ul><li>
      		<p><em>Use focus and blur events (or event delegation) to track the current focus</em> - <code>focus</code> and <code>blur</code> events can now be used with every element. There is no standard DOM interface to get the current element with keyboard focus, so authors may keep track of it with a <a href="https://developer.mozilla.org/en/JavaScript" title="JavaScript">JavaScript</a> variable. Don't assume that all focus changes will come via key and mouse events, because assistive technologies such as screen readers can set the focus to any focusable element, and that needs to be handled elegantly by the JavaScript widget. Techniques such as "event delegation" (for example, intercepting events on a list rather than on every listitem) can greatly increase web application performance and code maintainability, and authors are encouraged to use JavaScript best practices whenever possible. </p>
      	</li><li>
        	<p><em>Follow keydowns to move focus</em> - A keydown event handler can determine the next object to receive focus and call that element's focus() method. </p>
        </li><li>
        	<p><em>Use onkeydown to trap key events, not onkeypress</em> - Key press events do not fire for all keys and they vary across browsers. </p>
        </li><li>
        	<p><em>Dynamically change focusability using the tabIndex property</em> - You may want to update tabindex values if a custom control becomes disabled or enabled. Disabled controls should not be in the tab order. However, you can typically arrow to them if they're part of grouped navigation widget.  When an element receives focus, it should change the tabindex value to 0 to make an element the default element of the widget.  This is important if the user leaves the widget and returns to the widget again so focus is on the last element of the widget the user was on.  If other elements of a widget can receive keyboard focus, only one element of the widget should have a tabindex value of 0.</p>
        </li><li>
        	<p><em>Use element.focus() to set focus</em> - Do not use createEvent(), initEvent() and dispatchEvent() to send focus to an element, because these functions do not change the focus.  DOM focus events are informational only, generated by the user agent after an element has acquired focus, but not used themselves to set focus.</p>
        </li><li>
        	<p>The use of :focus pseudo-class selectors to style the keyboard focus is not supported in many versions of Internet Explorer. Authors should use the :active pseudo-class (which older versions of IE treat like :focus) in conjunction with the :focus pseudo-class. Example: a:focus, a:active { text-decoration: underline; } </p>
			<p>If the related CSS pseudo-classes are not appropriate or not supported in all browsers, authors can use JavaScript techniques to indicate an appropriate focus alternative, such as using focus and blur events to toggle a classname on an element.</p>
        </li><li> 
        	<p><em>Always draw the focus for tabindex="-1" items and elements that receive focus programmatically when supporting versions of Internet Explorer older than 8</em> - Choose between changing the background  color via something like this.style.backgroundColor = "gray"; or add a dotted border via this.style.border = "1px dotted invert".  In the dotted border case, you will need to make sure those elements  have an invisible 1px border to start with, so that the element doesn't  grow when the border style is applied (borders take up space, and IE  doesn't implement CSS outlines). </p>
        </li><li>
        	<p><em>Prevent used key events from performing browser functions</em> - If a key such as an arrow key is used, prevent the browser from using the key to do something (such as scrolling) by using code like the following:</p>
        	<pre class="example" xml:space="preserve"><span class="tag">&lt;span tabindex=<span class="str">"-1"</span> onkeypress=<span class="str">"return  handleKeyPress();"</span>&gt;</span> </pre>
        	<p>If handleKeyDown() returns false, the event will be consumed, preventing the browser from performing any action based on the keystroke.  In addition to the return value the browser must call the event methods that will prevent the default action, for IE this is setting the event property "returnValue=false", and for other browsers supporting the W3C event model this means calling the "preventDefault" method of the event object.</p>
        	</li><li>
        	<pre class="example" xml:space="preserve"><span class="tag">&lt;span tabindex=<span class="str">"-1"</span> onkeydown=<span class="str">"return handleKeyDown();"</span>&gt;</span>   </pre>
        	<p>If handleKeyDown() returns false, the event will be consumed, preventing the browser from performing any action based on the keystroke. </p>
        	</li><li>
          	<p><em>Use key event handlers to enable activation of the element</em> - For every mouse event handler, a keyboard event handler is required. For example, if you have an <em>onclick="doSomething()"</em> you may also need <em>onkeydown="return event.keyCode != 13 || doSomething();" </em>in order to allow the Enter key to activate that element. </p>
			<p class="note">Note: There are <a href="http://wiki.codetalks.org/wiki/index.php/Docs/Keyboard_navigable_JS_widgets">user agent-specific considerations</a> for key event handling.</p>
        </li><li>
        	<p>Consider using a "<a href="#kbd_general_within">roving</a>" tabindex for complex widgets if you are not using the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> property. </p>
        </li></ul>
    </div>
    <div class="section" id="focus_activedescendant">
      <h4><span class="tocnum">3.2.2. </span>  Using activedescendant to Manage Focus for Widget Children</h4>
      <p>In addition to tabindex, WAI-ARIA provides  the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> property  for managing the focus of child elements within a widget. Widgets like <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#grid"><code>grid</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tree"><code>tree</code></a> typically manage their children. The root element of the widget should have a <code>tabindex</code> value greater than or equal to "0" to ensure that the widget is in the document tabbing order. Rather than setting a key event handler on each element within a larger component, the event handler can be set on the parent element such as the tree. It is then the job of the parent element to manage the focus of the children. </p>
      <p> The parent may use the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> property to indicate the active child. For example, the container element with the role of tree can provide an onkeydown event handler so that each individual tree item within the tree does not need to be focusable and to listen for the keydown event. The container object, in this case the tree, needs to maintain the point of regard and manage which individual child item must be perceived as active.</p>
      <div class="note">
        <p><em>Important: For a given container widget where activedescendant must cause focus events to be fired to ATs, the actual focus must be on the container widget itself. In HTML this is done by putting tabindex="0" on the container widget.</em></p>
      </div>
      <p>The key handler on the parent captures the keystrokes and determines what item becomes active next and updates the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> property with the ID of the appropriate, next active child element. The browser takes that ID information and generates the focus event to the assistive technology. Each individual element does not have to be made focusable via a <code>tabindex</code> value of -1, but it must be styled using CSS to indicate the active status</p>
    </div>
    <div class="section" id="visualfocus">
      <h4><span class="tocnum">3.2.3. </span> Managing Visual Focus with tabindex Alone </h4>
      <p>An alternative to using activedescendant is to have the parent element, in response to the same keyboard input, move focus to its children by first removing <code>tabindex</code> from children that do not have focus, which removes them from the tab order. This would be followed by setting the <code>tabindex</code> to "-1" on the element that is to receive focus and then using script to set focus on the element to receive focus. As with <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a>, this omits managed children from the tabbing order. It enables browsers that do not yet support <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> to maintain keyboard navigation, and it provides notification to many assistive technologies like screen magnifiers to move visual focus without relying on other WAI-ARIA properties. Today, this technique will work in most user agents, but in the long run <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> will require less work by the developer.</p>
      <p>Although not always ideal based on the widget you are creating, one benefit of using tabindex to manage focus on an element is that the user agent will scroll the element into view when focus is set to the it. This is not the case for <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a>. When setting or updating the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> property, e.g. <code>aria-activedescendant="cell23"</code>, authors must ensure that the   element with <code>id="cell23"</code> is in view. In either case, consider positioning your widget in the visible area of your browser to maximize usability. This can be achieved using available JavaScript scrolling functions.</p>
    </div>
    <div class="section" id="scrollintoview">
      <h4><span class="tocnum">3.2.4. </span> Managing Focus with Scroll</h4>
      <p>In some browsers, a JavaScript call to <code> scrollIntoView()</code> on this element should suffice, but in browsers where   this is unreliable, authors should explicitly set the <code>scrollTop</code> and <code>scrollLeft</code> properties of the "cell23" element and its ancestors to scroll the element into view. <code>scrollTop</code> and <code>scrollLeft</code> adjust the node positions by the amounts(pixels) needed to scroll a node into view.  Scrolling values are adjusted by the amounts(pixels) needed 
        to scroll a node into view. This is done by comparing the sizes of the nodes 
        using available measurements such as scroll+offset+clientWidth/Height/Left/Top. It's important to note that you have to adjust a node so that it's viewable within 
        the context of its parent node.  Then you have to move up the DOM tree and make 
        each parent node visible.</p>
      <p>For example, create a custom <code> scrollIntoView()</code> method that is called at various   times, including coincidence with the setting of the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> property. The method takes a DOM node   argument, say "n". Here is the high level algorithm: </p>
      <ol><li> If n is already in view, stop; otherwise, continue. </li><li> adjust n.scrollTop and n.scrollLeft such that it is in view. </li><li>adjust scrollTop and scrollLeft for the ancestor nodes of n such that   that the region of the ancestors which n consumes is visible.</li></ol>
      <p>This is a minimum-position-change algorithm. </p>
      <p>Understanding how the DOM scrollIntoView works across browsers is important. 
        Browsers (including Firefox3) force the node either to the top or the bottom of the screen (as defined by the single Boolean parameter) even if its already in view. This is problematic when you only need to scroll horizontally to see the element. It is also problematic when  the node is partially off the bottom of the screen and the parameter is (true) which forces the node all the way to the top, and vice versa with the top going to the bottom on (false). IE forces the node to the left of the client area (or right in right-to-left mode) even if it's horizontally in view already. </p>
      <p>The <code>scrollTop</code> and<code> scrollLeft</code> functions create some challenges. <code>scrollTop</code> is always accurate but misleading with respect to inner (nested) scrollbars.<code> scrollLeft</code> cannot be relied on in right-to-left languages because it is sometimes negative and sometimes positive especially with respect to inner (nested) scrollbars. Different browsers handle right-to-left completely differently. </p>
    </div>
    <div class="section" id="dualfocus">
    	<h4><span class="tocnum">3.2.5. </span> Managing the Perception of a Dual Focus</h4>
    	<p>Often applications give the  perception of having a dual focus. Two examples of this are multi-selection list boxes and selected tabs, within a tablist, when focus is in a tabpanel. In the case of a muti-selection list box a developer may gray selected items as they move focus to list box items to toggle their selected state. In the case of a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tabpanel"><code>tabpanel</code></a> the user selects a tab but then navigates to a focused item in the corresponding <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tabpanel"><code>tabpanel</code></a> the tab appears to also have focus. In reality, only one element may have focus in an application. In these scenarios authors should ensure keyboard focus is set on the current element that visibly receives keyboard user input while ensuring other "highlighted" elements have an aria-selected state of "true" until de-selected. When the de-selection occurs, such as when a multi-select item is de-selected or a user moves to a new tab and de-select the old tab, the author should ensure that the visible selection of the de-selected item is removed.</p>
    </div>
    <div class="section" id="AuthDefKeys">
      <h4><span class="tocnum">3.2.6. </span>  Author-Defined Keyboard Short-Cuts or Mnemonics </h4>
      <p>Author-defined keyboard short-cuts or mnemonics present a high risk for assistive technology users. Because they are device-, browser-, and AT-dependent, conflicts among key bindings are highly probable. Therefore, if you needed to use <a href="http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.11.2">accesskey</a>,  you should be aware that  it will behave differently in <br clear="none"/>
        different browsers. It also may not work with small devices so it is still advisable to ensure that all features are accessible with the  basic keys like Tab/shift+tab, arrow, Enter, space and Escape. </p>
      <p>The XHTML 2 Working Group is currently developing a new <a href="http://www.w3.org/TR/xhtml-access/">Access Module</a> to address this issue and we hope to have it or a feature like it in future versions of (X)HTML.  Refer to <a href="#aria_ex">Section 9: Implementation Guidance</a>. </p>
      <div class="section" id="kbd_tooltips">
        <h5><span class="tocnum">3.2.6.1. </span>  Supporting Tooltips with the Keyboard</h5>
        <p>A <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tooltip"><code>tooltip</code></a> is a  popup messages typically triggered by moving a mouse over a control or widget causing a small popup window to appear with additional information about the control. To provide simple text tooltips, the <a href="http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.4.3">HTML title attribute</a> should more than suffice because the user agent will render it for tooltips. When creating a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tooltip"><code>tooltip</code></a>, it is essential that  the user be able to activate it using the keyboard. When a form control or widget receives keyboard focus, the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tooltip"><code>tooltip</code></a> must display. When the form control or widget loses focus, the tooltip must disappear. Browsers do not currently support this functionality. </p>
        <p>The following code snippet from the <a href="http://test.cita.uiuc.edu/aria/tooltip/tooltip1.php" title="iCITA"><acronym title="Illinois Center for Information Technology Accessibility">iCITA</acronym></a> site shows the use of a <span class="example">onfocus="tooltipShow()</span> function to display the tooltip when focus is placed on an element. </p>
        <pre class="example" id="line1" xml:space="preserve"><span class="tag">&lt;html lang=<span class="str">"en-us"</span>"&gt;</span>  
<span class="tag">&lt;head&gt;</span>    
   <span class="tag">&lt;title&gt;</span>inline: Tooltip Example 1<span class="tag">&lt;/title&gt;</span>      
   <span class="tag">&lt;link rel=<span class="str">"stylesheet"</span> href=<span class="str">"css/tooltip1_inline.css"</span>  type=<span class="str">"text/css"</span>&gt;</span>    
   <span class="tag">&lt;script type=<span class="str">"text/javascript"</span> src=<span class="str">"js/tooltip1_inline.js"</span>&gt;</span><span class="tag">&lt;/script&gt;</span>    
   <span class="tag">&lt;script type=<span class="str">"text/javascript"</span> src=<span class="str">"../js/widgets_inline.js"</span>&gt;</span><span class="tag">&lt;/script&gt;</span>
   <span class="tag">&lt;script type=<span class="str">"text/javascript"</span> src=<span class="str">"../js/globals.js"</span>&gt;</span><span class="tag">&lt;/script&gt;</span>          
   <span class="tag">&lt;link rel=<span class="str">"icon"</span> href=<span class="str">"http://www.cites.uiuc.edu/favicon.ico"</span> type=<span class="str">"image/x-icon"</span>&gt;</span>    
   <span class="tag">&lt;link rel=<span class="str">"shortcut icon"</span> href=<span class="str">"http://www.cites.uiuc.edu/favicon.ico"</span> type=<span class="str">"image/x-icon"</span>&gt;</span> 
<span class="tag">&lt;/head&gt;</span>
   ...   

   <span class="tag">&lt;body onload=<span class="str">"initApp()"</span>&gt;</span>

   <span class="tag">&lt;div id=<span class="str">"container"</span>&gt;</span>

   <span class="tag">&lt;h1&gt;</span>Tooltip Example 1<span class="tag">&lt;/h1&gt;</span>
     <span class="tag">&lt;h2&gt;</span>Create Account<span class="tag">&lt;/h2&gt;</span>
   <span class="tag">&lt;div class=<span class="str">"text"</span>&gt;</span>
   <span class="tag">&lt;label for=<span class="str">"first"</span>&gt;</span>First Name:<span class="tag">&lt;/label&gt;</span> 

   <span class="tag">&lt;input type=<span class="str">"text"</span>  id=<span class="str">"first"</span> name=<span class="str">"first"</span> size=<span class="str">"20"</span> 
          onmouseover=<span class="str">"tooltipShow(event, this, 'tp1');"</span>     
          onfocus=<span class="str">"tooltipShow(event, this,  'tp1');"</span> 
          aria-describedby=<span class="str">"tp1"</span>  		 
          aria-required=<span class="str">"false"</span>/&gt;</span>

   <span class="tag">&lt;div id=<span class="str">"tp1"</span> role=<span class="str">"tooltip"</span> aria-hidden=<span class="str">"true"</span>&gt;</span>Your first name is optional. <span class="tag">&lt;/div&gt;</span>    
   <span class="tag">&lt;/div&gt;</span>
  ...
            </pre>
      </div>
      <div class="section" id="kbd_stolen_keys">
        <h5><span class="tocnum">3.2.6.2. </span> When Keyboard Handlers Shortcuts Steal the Keys</h5>
        <p>
        Similar to the tip specified in <a href="#focus_tabindex">Using Tabindex to Manage Focus on Widgets</a>, a web application should cancel (or swallow) the keyboard event in the keyboard handler to prevent the key from being used outside the web application. For example if the user presses Control+PageDown in a tab panel in a web application, this keyboard event should not also go to the user agent, which would cycle the active browser tab, confusing the user.
        </p>
      </div>
      
    </div>
    <div class="section" id="kbd_layout">
      <h4><span class="tocnum">3.2.7. </span>  Providing Navigable Structure within Web Pages</h4>
      <p>This section takes a broader look at the Web page. It is intended to assist you in conveying a logical, usable, and accessible layout to an assistive technology or adaptive system designed to modify the visual layout to meet the users needs. </p>
      <p>One of the deficiencies of (X)HTML for disabled users has been the  usability of keyboard navigation. Users dependent on a keyboard for  navigation have been forced to tab everywhere in the document, as the  only keyboard accessible document elements are form and  anchor elements. This has forced developers to make most everything a  link to make it keyboard accessible, and to get to each link you have  to tab to it. With the advent of portals and other content aggregation  means Web pages are divided into visible regions and there has been no  vehicle to get to them other than perhaps to do things such as: </p>
      <ul><li>Create a skip link at the top of the page to the main content </li><li>Make the head of each perceivable region (search bar, stock quote, TV Listing, etc.) an <code>&lt;H1&gt;</code> tag </li></ul>
      <p>There are number of problems with this approach: </p>
      <ul><li>Both force the user interface to change to support accessibility </li><li>In the case of using <code>&lt;H1&gt;</code> to mark your regions, this is not consistent across Web sites </li><li>The semantics are limited to main content and a section</li><li>Neither  convey the need for the  rich internet application developer to control keyboard navigation to an assistive technology</li></ul>
      <p>This remainder of this section provides the author with a playbook for using WAI-ARIA to add semantically rich navigation structure in a Web page so that an assistive technology may provide an effective  user experience and avoid these shortcomings.</p>
      <div class="section" id="kbd_layout_landmarks">
        <h5><span class="tocnum">3.2.7.1. </span>  Steps for Defining a Logical Navigational Structure</h5>
        <p>Follow these steps to mark each logical section: </p>
        <ol><li>
            <p><a id="kbd_layout_landmark_IDRegions" name="kbd_layout_landmark_IDRegions"></a><strong>Identify the logical structure of your page</strong></p>
            <p>Break up your page into perceivable block areas which contain semantically associated information called "regions". You can further break down each region into logical regions as needed. This is a common process undertaken by portal developers who break the page into perceivable regions called portlets. Think about the user wanting to navigate to these logical block areas on your Web page. Write down a description of what you believe each region to be.</p>
            <p> Depending on your Web application you may then need to break it into sub regions depending on the complexity of your Web application. This is a recursive process. A user will look at these perceivable areas like pealing an onion. You might have an outermost collection of perceivable regions or block areas and upon entering each region you may have a collection of regions within it. </p>
          </li><li>
            <p><a id="KBD_logicalstructuremarkup" name="KBD_logicalstructuremarkup"></a><strong>Implement the logical structure in markup</strong></p>
            <p>Implementing the block structure in markup often involves wrapping elements contained with a "region" such as a <code>&lt;div&gt;</code> or <code>&lt;iframe&gt;</code> with visible borders so that each region or block is perceivable to the user.</p>
          </li><li>
            <p><a id="KBD_layout_labelregion" name="KBD_layout_labelregion"></a><strong>Label each region</strong></p>
            <p> Once you have broken up each region you need to label it. The start of each region must have a perceivable header and it should be used to label the region. For details on how to do this see section <a href="#kbd_layout_nesting_vs_level">3.4.3.1 Header Levels vs. nesting level</a> to create a header to label each region. If you're finding it difficult to come up with a label for the region, make sure at least to use one of the standard roles defined in the following step. The drawback of not providing a label is that users will not know the purpose of the region. By definition, regions would be included in a summary of a page. If an assistive technology were to summarize it would be unable to provide information about the section without a label.</p>
          </li><li>
            <p><a id="kbd_layout_landmark_XHTML" name="kbd_layout_landmark_XHTML"></a><strong>Assign landmark roles to each region</strong></p>
            <p>Now that you labeled your regions, you need to assign them semantic navigation landmarks. Landmarks are a vast improvement over the rudimentary "skip to main content" technique employed prior to WAI-ARIA. If possible it is best to use these as landmarks. Skip to main content links may impact the placement of web application elements. This may be a consideration for developers that want to try to keep their web application in a specific visible area. Consequently, layout adjustments may need to be made to support skip to main content links. Also, skip to main content links are limited in that they only address only one main content area. WAI-ARIA provides a collection of landmarks which are applied to each of the regions you identified in step 2. </p>
            <p> The presence of  common, semantic, navigation  landmarks allows each site to support the same standard and allows your  assistive technology to provide a consistent navigation experience - an important feature for screen readers and alternate input solutions. For users with cognitive and learning disabilities the landmark information could be used to expand and collapse these regions of your page to aid in simplifying the user experience by allowing the user to manage the amount of information processed at any one time. </p>
            <p> There are also mainstream benefits of providing navigation landmarks. Your browser may assign key sequences to move focus to these sections as they can be set on every site. Navigation to these landmarks is device independent. A personal digital assistant (PDA) could assign a device key to get to them in your document. The common landmarks in WAI-ARIA include: </p>
            <dl><dt><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#application"><code>application</code></a></dt><dd>
Represents a region of the page representing a unique software unit executing a set of tasks for its users. It is an area where assistive technologies should also return browse navigation keys back over to the web application in this region. 
  <p class="note">If the entire web page has a role of application then it should not be treated as a navigational landmark by an assistive technology.</p>
</dd><dt><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#banner"><code>banner</code></a> </dt><dd>A region that contains the prime heading or internal title of a page. </dd><dt><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#complementary"><code>complementary</code></a> </dt><dd>Any section of the document that supports but is separable from the main   content, but is meaningful on its own even when separated from it. </dd><dt><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#contentinfo"><code>contentinfo</code></a> </dt><dd>Meta information which applies to the first immediate ancestor whose role is   not presentation.</dd><dt><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#form"><code>form</code></a></dt><dd>A region of the document that represents a collection of form-associated elements, some of which can represent editable values that can be submitted to a server for processing.</dd><dt><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#main"><code>main</code></a> </dt><dd>Main content in a document. </dd><dt><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#navigation"><code>navigation</code></a> </dt><dd>A collection of links suitable for use when navigating the document or   related documents.</dd><dt><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#search"><code>search</code></a> </dt><dd>The search tool of a Web document. </dd></dl>
            <p>To set the landmark in your page: </p>
            <pre class="example" xml:space="preserve">&lt;div role="log" title="chat log"&gt;
&lt;div role="region" title="Game Statistics"&gt;  </pre>
          </li><li><a id="kbd_layout_static" name="kbd_layout_static"></a><strong>For application landmarks with static prose</strong>
       <p>
       If you have a regional landmark of type application and static descriptive text is available, then on the application landmark, include an aria-describedby reference to associate the application and the static text as shown here:</p><pre xml:space="preserve"><span class="tag">&lt;div role=<span class="str">"applicaton"</span> aria-labelledby=<span class="str">"calendar"</span> aria-describedby=<span class="str">"info"</span>&gt;</span>
<span class="tag">&lt;h1 id=<span class="str">"calendar"</span>&gt;</span>Calendar<span class="tag">&lt;h1&gt;</span>
<span class="tag">&lt;p id=<span class="str">"info"</span>&gt;</span>
This calendar shows the game schedule for the Boston Red Sox.
<span class="tag">&lt;/p&gt;</span>
<span class="tag">&lt;div role=<span class="str">"grid"</span>&gt;</span>
....
<span class="tag">&lt;/div&gt;</span></pre>
       </li><li><a id="kbd_layout_landmark_rebel" name="kbd_layout_landmark_rebel"></a><strong>For  landmarks unsuited to specialized region WAI-ARIA roles</strong>
            <p>You can create custom regional landmarks by using a generic <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#region"><code>region</code></a>. While it is not essential to label these specialized regions with a header, you should provide a title to ensure that the region name is accessible to all users, just as you would the <a href="#kbd_layout_landmark_XHTML">standard regional landmarks</a>. See <a href="#kbd_layout_nesting_vs_level">Header levels versus Nesting levels</a> for directions on how to label the region.</p>
            <pre class="example" xml:space="preserve">&lt;div role="main"&gt; ... &lt;div role="region" title="weather"&gt;  
</pre>
            <p>Note: the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#region"><code>region</code></a> role is generic and should only be used when a more specific role is not applicable.</p>
          </li><li>
            <p><strong>Indicate to the assistive technology who controls the keyboard navigation</strong></p>
            <p> Today's screen readers for the blind have been designed to give the user a "browsing" experience meaning the screen reader consumes  a number of keys to aid in the browsing experience. For example, the "up" and "down" arrow keys are used to read the next and previous line of text on your Web page. Accessible rich internet applications will use these keys in an application to navigate within "widgets" like a <a href="#TreeView">Tree View</a>.</p>
            <p> Assistive technologies must be able to identify widgets which implement WAI-ARIA and allow them use of the keyboard. However, if you have used  numerous widgets to form an application you must set the role on the encompassing region to <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#application"><code>application</code></a>. Should you have regions which should be browsed as documents within the application region you should mark those regions with a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#document"><code>document</code></a> role as needed. See section <a href="#kbd_layout_impact">3.4.2 Structural Roles used to facilitate assistive technology navigation</a>.          </p>
          </li></ol>
      </div>
      <div class="section" id="kbd_layout_impact">
        <h5><span class="tocnum">3.2.7.2. </span>  Structural Roles that Facilitate  Navigation with Assistive Technologies</h5>
        While WAI-ARIA is designed to address many disabilities, this section is best described in terms of screen reader use. In desktop applications, screen readers typically treat widgets as discrete entities, reading and interacting with each widget one at a time. The user moves the point of focus from widget to widget using tab/shift tab, mnemonics, or accelerators, keyboard commands which are usually provided by the application or the operating system. We refer to this mode of interaction as "application mode."
        <p>When viewing Web content however, screen readers often gather information about all the widgets in an area and present them in a document-like view which the user navigates using keyboard commands provided and controlled by the screen reader. Think of this mode as a virtual environment that presents Web content in a way that makes it convenient for adaptive technology users to navigate and read. This is sometimes called browse mode, or virtual mode. We refer to this as "document browse mode." </p>
        <p>Because many screen readers provide document mode navigation support using single key mnemonics on the alpha-numeric keyboard, they may provide a third mode, called "forms mode," used to interact with form controls that are encountered in document mode. Behavior in forms mode is similar to that of application mode. The key feature of forms mode is that it can be toggled with document mode to make it easy to both interact with a specific widget, and read virtualized content of which the widget is a part. Since, as described above, a screen reader's perception of an area as either a document or an application greatly influences how the user reads and interacts with it, WAI-ARIA provides content authors a way to indicate whether their pages must be viewed as applications or documents by assistive technologies. </p>
        <p>To set document or application mode follow these steps: </p>
        <ol><li>
            <p><a id="kbd_layout_impact_approle" name="kbd_layout_impact_approle"></a><strong>Set the Application Role</strong></p>
            <p>After you have divided your Web page into regions through the use of role landmarks and custom regions, you must make a decision: Is your Web page an application or not? If the majority of the content is application-like the default interaction mode should be set to <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#application"><code>application</code></a>, with <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#document"><code>document</code></a> regions embedded within the application if applicable. Otherwise the default interaction mode is document-like and therefore should not be overridden by the use of a global role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#application"><code>application</code></a>. In this case the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#application"><code>application</code></a> role can be placed on discrete regions within the document if applicable. </p>
			<p>If it is, set the role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#application"><code>application</code></a> on the body tag as follows: </p>
            <pre class="example" xml:space="preserve">&lt;body role="application"&gt; </pre>
            <p> When using <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#application"><code>application</code></a>, all static text must be associated with widgets, groups or panes via using the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> properties, otherwise it will not be read by the screen reader when the user navigates to the related widget or group.</p>
            <p>Special Considerations: </p>
            <ul><li>If you have selected to have a role of application on the body tag, it is recommended that a widget have focus after the page is first loaded. There may be an instance when an application itself needs to receive focus, such as an application consisting solely of a scrollable editable text area. </li><li>If when your page loads and you should have  focus on a widget this is a strong indicator that your Web page should have role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#application"><code>application</code></a>.</li><li>If your page has only a few isolated widgets, like pop-up calendars located on a Web page, it is not necessary to expressly set the role of application on the body. Screen readers, based on widget roles, must be able to provide access to these widgets without recognizing the entire page as an application. </li><li>Also, browsers make use of a feature called the contenteditable attribute, which will be incorporated into HTML 5. Contenteditable allows an author to turn the browser section into a rich text editor, similar to a word processor. Any section which has contenteditable set to "true" is considered a widget. </li><li>If the body element has been given the role of application, please follow step 3. Otherwise, the Web page is considered a document, and no further action is required in this regard. </li></ul>
          </li><li><strong>Dialogs and alert dialogs - special case application roles</strong>
            <p> WAI-ARIA provides <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#dialog"><code>dialog</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alertdialog"><code>alertdialog</code></a> roles that are to be treated as special case <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#application"><code>application</code></a> roles. Like application, screen readers will leave the main job of  keyboard navigation up the dialog. </p>
            <p> When using <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#dialog"><code>dialog</code></a>, all static text must be associated with widgets, groups or panes using the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> properties, otherwise it will not be read by the screen reader when the user navigates to the related widget or group. Unlike an application, your Web page is unlikely to start out as either of these two roles but rather the author is most likely to dynamically create dialogs or alertdialog sections within the Web page.</p>
            <p> Unlike <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#dialog"><code>dialog</code></a>, descriptive text of the alert does not need to be associated via a relationship, as the contents of alert dialogs will be read automatically by the screen reader when the dialog opens.          </p>
          </li><li><strong>Set the document role</strong> </li></ol>
        <blockquote>
          <p>The default mode for a screen reader to be processing an HTML Web page is document browse mode. This is equivalent to having a role of document on the HTML <code>&lt;body&gt;</code> tag. If you have already specified a role of application on the body tag there may be times in which you tell the screen reader to switch into "document browse mode" and start stealing the necessary keys to browse a document section of your Web page. These keys are the typical keys used by WAI-ARIA widgets and to provide this level of navigation the keys must be stolen from your browser. </p>
          <p>To mark areas of your page to tell the assistive technology when to switch into document browse mode, look at the regions/landmarks you have defined and determine which ones must be browsed as a document or navigated as an application. For each region which must be browsed in document browse mode, embed a div element within it with the role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#document"><code>document</code></a> as follows: </p>
          <pre class="example" xml:space="preserve">&lt;div role="document"&gt; </pre>
          <p>Now, when a screen reader encounters this region, it will change its interaction model to that of  document browsing mode. </p>
        </blockquote>
      </div>
      <div class="section" id="kbd_layout_nesting">
        <h5><span class="tocnum">3.2.7.3. </span>  Implicit Nesting and Headings </h5>
        <p>This section discusses the use of the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#heading"><code>heading</code></a> role and nesting levels. </p>
        <div class="section" id="kbd_layout_nesting_vs_level">
          <h6><span class="tocnum">3.2.7.3.1. </span>  Header Levels Versus Nesting Levels </h6>
          <p>The <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#heading"><code>heading</code></a> role value signifies a heading for a section of the document instance. Use of the heading role indicates that a specific object serves as a header. The <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#region"><code>region</code></a> of the document to which the heading pertains to should be marked with the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> property containing the value of the id for the header. If you have a heading and there is no element containing the content that it heads, wrap the content in a &lt;div&gt; bearing this <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> attribute. If headings are organized into a logical outline, the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-level"><code>aria-level</code></a> property can be used to indicate the nesting level. Here is an example:</p>
          <pre class="example" xml:space="preserve">&lt;p role="main" aria-labelledby="hdr1"&gt;

 &lt;div role="header" id="hdr1" aria-level="1"&gt;
    Top News Stories

 &lt;/div&gt;

&lt;/p&gt;</pre>
        </div>
        <div class="section" id="kbd_layout_nesting_owns">
          <h6><span class="tocnum">3.2.7.3.2. </span> Owns Repairs Nesting</h6>
          <p>Assistive technology briefs users on the context where they are. When they arrive at a new page, a page summary may be given. When they move into a new context, some of the labeling from elements containing the new focus or reading location may be rendered by the assistive technology, to give context to the details to be read next. </p>
          <p>The syntactic structure of a page provides the default nesting of contexts. If a paragraph is nested in a &lt;div&gt; or table cell, it is assumed that labels for the &lt;div&gt; or headers for the table cell are pertinent to what is in the paragraph. On the other hand, it is not possible to always flow the logical structure one-to-one into the parse structure. </p>
          <p>The <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> relationship is provided to annotate logical nesting where the logical child is not a syntactic descendant of the logical parent. In a Rich Internet Application, updates may be made to the document without updating the logical syntactic structure, yet elements may appear to be added to the document structure. From a DOM and accessibility hierarchy perspective <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> is a fallback mechanism to using the tree hierarchy provided in the DOM. An example  of where <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> is needed is a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treeitem"><code>treeitem</code></a>, where children in a folder subtree are added to a visible subtree but not reflected in the actual document subtree of the folder. The <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> relationship can be used to associate the folder with the new "adopted" child. For more details on the use of <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> see <a href="#relations_owning">section 4.2 Owning and Controlling</a>. The <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> relationship is used to indicate to a user agent that a menu is an adopting parent of a sub <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menu"><code>menu</code></a>.  Another use for <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> is a hierarchical diagram  where the child nodes of the diagram are not be adequately represented using the DOM structure. </p>
        </div>
      </div>
      <div class="section" id="kbd_layout_groupheading">
        <h5><span class="tocnum">3.2.7.4. </span>  Directories, Groups, and Regions</h5>
        <p>There are several WAI-ARIA roles used to indicate a collection of user interface objects, and each has a distinct purpose:</p>
        <dl><dt> <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#directory"><code>directory</code></a> </dt><dd>Contains a static table of contents </dd><dt><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#group"><code>group</code></a></dt><dd>Small set of related user interface objects that would not be included in a page summary or table of contents by an assistive technology</dd><dt><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#region"><code>region</code></a></dt><dd>Section of related user interface objects that should be included in a page summary or table of contents. </dd></dl>
        <p>The use of each is described below. </p>
        <div class="section" id="kbd_layout_directories">
          <h6><span class="tocnum">3.2.7.4.1. </span>  Directories and Their Applicability </h6>
          <p>The WAI-ARIA role, <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#directory"><code>directory</code></a>, allows authors to mark static table of content sections of a document. Prior to WAI-ARIA, the user would need to guess if an area of a document actually pertained to the table of contents. Authors should mark these sections within a document with a role of  directory.</p>
          <pre class="example" xml:space="preserve">&lt;div role="directory"&gt;
   &lt;ul&gt;
      &lt;li&gt;Global Warming Causes
          &lt;ul&gt;
             &lt;li&gt;CO2 Buildup&lt;/li&gt;
             &lt;li&gt;Auto emissions&lt;li&gt;
             &lt;li&gt;Factory emissions&lt;/li&gt;
             &lt;li&gt;Destruction of rainforests&lt;/li&gt;
          &lt;/ul&gt;

      &lt;/li&gt;

      &lt;li&gt;Tailoring CO2 buildup
          &lt;ul&gt;
             &lt;li&gt;Elimination of the incandescent light bulb&lt;/li&gt;
             &lt;li&gt;Hydrogen fuel cells&lt;/li&gt;
             &lt;li&gt;Solar energy&lt;/li&gt;
             &lt;li&gt;Wind power&lt;/li&gt;
          &lt;/ul&gt;

      &lt;/li&gt;  
   &lt;/ul&gt;

&lt;/div&gt;</pre>
        </div>
        <div class="section" id="kbd_layout_whatgroup">
          <h6><span class="tocnum">3.2.7.4.2. </span>  Groups and Their Applicability </h6>
          <p>Authors should use a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#group"><code>group</code></a> to form logical collections of items with related functionality in a widget. A group should not be considered a major perceivable section on a page. A <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#group"><code>group</code></a> neither has a heading nor appears in the "Table of Contents."  A <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#group"><code>group</code></a> may  delineate a set of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treeitem"><code>treeitem</code></a>s having the same level in the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tree"><code>tree</code></a> or it may be used to group a set of related checkboxes in a form. Other examples include: </p>
          <ul><li>a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#row"><code>row</code></a> in a grid (a row is a specialized group representing a row in a grid); </li><li>a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#group"><code>group</code></a> of children in a tree widget forming a collection of siblings in a hierarchy; or </li><li>a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#group"><code>group</code></a> of items having the same container in a directory </li></ul>
          <p>Proper handling of a group by assistive technologies, therefore, is determined by the context in which it is provided. Group members that are outside the DOM subtree of the group need to have explicit relationships assigned for them in order to participate in the group. Groups may also be nested. </p>
          <p>If an author believes that a section is significant enough in terms of the entire document instance, then the author must assign the section a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#region"><code>region</code></a> or one of the designated standard landmarks. The designated landmark roles are listed in the section <a href="#kbd_layout_landmarks">Regions and XHTML Role landmarks</a>..</p>
        </div>
        <div class="section" id="kbd_layout_whatregion">
          <h6><span class="tocnum">3.2.7.4.3. </span>  Regions and Their Use </h6>
        	<p>When defining a region for a section of a document, authors must consider using standard document landmark roles defined in the <a href="http://www.w3.org/1999/xhtml/vocab/">XHTML Vocabulary</a>. This makes it possible for user agents and assistive technologies to treat roles as standard navigation landmarks. If the definition of these regions is inadequate, authors must use the WAI-ARIA <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#region"><code>region</code></a> role and provide the appropriate title text. </p>
          <p>For more information on the use of region see <a href="#kbd_layout_landmarks">Regions and XHTML Role landmarks</a>.</p>
          <p> </p>
        </div>
      </div>
      <div class="section" id="kbd_layout_remaining">
        <h5><span class="tocnum">3.2.7.5. </span>  Remaining Structural Roles</h5>
        <ul><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#columnheader"><code>columnheader</code></a> </li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#directory"><code>directory</code></a></li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#grid"><code>grid</code></a> </li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#gridcell"><code>gridcell</code></a></li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#img"><code>img</code></a> </li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#list"><code>list</code></a> </li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listitem"><code>listitem</code></a></li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#row"><code>row</code></a> </li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#rowheader"><code>rowheader</code></a></li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#separator"><code>separator</code></a> </li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treegrid"><code>treegrid</code></a></li></ul>
        <div class="section" id="kbd_layout_remaining_tabular">
          <h6><span class="tocnum">3.2.7.5.1. </span>  Tabular Structure-Related Roles Supporting Tabular Widgets</h6>
          <p>A number of structural roles support the tabular widgets, <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#grid"><code>grid</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treegrid"><code>treegrid</code></a>. These structural roles indicate additional keyboard navigation as well as the ability to select rows and/or columns. Typically, you would apply these roles to an underlying table in the base markup as shown here:</p>
          <pre class="example" xml:space="preserve">&lt;table role="grid"&gt;		</pre>
          <p>However, that may not work for the developer in all instances, such as when the developer has need for a &lt;div&gt; or &lt;span&gt; or when additional semantics are needed. To assist, the following roles are provided to support tabular widgets:</p>
          <ul><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#columnheader"><code>columnheader</code></a> </li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#grid"><code>grid</code></a> </li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#gridcell"><code>gridcell</code></a></li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#row"><code>row</code></a> </li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#rowheader"><code>rowheader</code></a></li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treegrid"><code>treegrid</code></a></li></ul>
          <p>When constructing a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#grid"><code>grid</code></a>or <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treegrid"><code>treegrid</code></a> the author must use <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#gridcell"><code>gridcell</code></a>s for the actual cells:</p>
          <pre class="example" xml:space="preserve">&lt;table role="grid"&gt;
   &lt;tr&gt;
      &lt;td role= "columnheader"&gt;Apples&lt;/td&gt;&lt;td role= "columnheader"&gt;Oranges&lt;/td&gt;
   &lt;/tr&gt;
   &lt;tr&gt;
      &lt;td role="gridcell"&gt;Macintosh&lt;/td&gt;&lt;td role="gridcell"&gt;Valencia&lt;/td&gt;
   &lt;/tr&gt;
&lt;/table&gt;</pre>
          <p>Unlike table cells within a table, authors should ensure a grid's  <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#gridcell"><code>gridcell</code></a>s are focusable through the use of tabindex (in HTML), or <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a> on the grid.They may also be editable, as is shown in the above example. </p>
          <p>Treegrid's may require expanding and collapsing rows which may not be performed using a &lt;tr&gt;. In these instances authors will use an HTML <code>&lt;div&gt;</code>. WAI-ARIA provides a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#row"><code>row</code></a> which may be assigned to the <code>&lt;div&gt;</code> to convey to the assistive technology that this is still a row. If you decide to not use the native HTML &lt;table&gt; elements and choose more flexible elements, such as <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code>s, with applied WAI-ARIA roles in this section, you should structurally lay out your elements in line with what you would expect from HTML. All of your <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#rowheader"><code>rowheader</code></a>s should be in a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#row"><code>row</code></a> and your <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#gridcell"><code>gridcell</code></a>s should be children of each subsequent row in the same format as HTML for <code>&lt;td&gt;</code>s and <code>&lt;th&gt;</code>s within <code>&lt;tr&gt;</code>s.</p>
        </div>
        <div class="section" id="kbd_layout_remaining_description">
          <h6><span class="tocnum">3.2.7.5.2. </span>  Marking Descriptive Sections</h6>
          <p>     
          A new feature of WAI-ARIA is the ability to associate descriptive text with a section, drawing, form element, picture, and so on using the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> property. This is unlike longdesc which typically required the author to create a separate file to describe a picture when it was preferred to have the descriptive text in prose as well so that it was readily available to all users. Yet, like longdesc descriptive text is treated separately from the short name you would typically provide using the title or alt attributes in HTML.
          </p>
          <pre class="example" xml:space="preserve">&lt;img src="foo" alt="abbreviated name" aria-describedby="prose1"&gt;

&lt;div id="prose1"&gt;
   This prose in this div describes in detail the image foo.
&lt;/div&gt;</pre>
          <p> This is the preferred vehicle for providing long descriptions for elements in your document.</p>
        </div>
      </div>
      <div class="section" id="misc_xhtml2_roles">
        <h5><span class="tocnum">3.2.7.6. </span>  Miscellaneous XHTML Section Roles</h5>
        <p>In order to be synchronized with the XHTML Role Attribute module, WAI-ARIA includes two XHTML roles which are neither landmarks or widgets of any kind. These roles were incorporated to replace standard elements found in host languages. These roles are <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#definition"><code>definition</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#note"><code>note</code></a>. If either role has a corresponding element in the host language it recommended that authors use the corresponding element in the host language.</p>
        <p>The <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#definition"><code>definition</code></a> role indicates a definition statement in your document. For HTML developers implementing lists of definitions, we recommend    you using the DL, DT, and DD elements rather than marking an arbitrary    element with a role of definition. An arbitrary element would be    appropriate for inline definitions used in conjunction with the DFN    element. </p>
        <p>Example of an inline definition with an explicit labelledby relationship:</p>
        <pre class="example" xml:space="preserve">
&lt;p&gt;The doctor explained it had been a &lt;dfn id="placebo"&gt;placebo&lt;/dfn&gt;, or &lt;span role="definition" aria-labelledby"placebo"&gt;  
or an inert preparation prescribed more for the mental relief of the patient than for its actual effect on a disorder.&lt;/span&gt;
&lt;/p&gt;</pre>
        <p><span class="example">Example inline definition with an implicit labelledby relationship    determined by nesting:</span></p>
        <pre class="example" xml:space="preserve">&lt;p&gt;The doctor explained it had been a &lt;span role="definition"&gt;
&lt;dfn&gt;placebo&lt;/dfn&gt;, an inert preparation prescribed more for the mental relief of the patient than for its actual effect on a disorder.&lt;/span&gt;
&lt;/p&gt;</pre>
        <p>Note: In the case where host language semantics do not allow for    implicit nesting of definitions terms inside definition roles, authors    should explicitly use the aria-labelledby attribute, even when the    definition term is nested in the definition as shown here:</p>
        <pre class="example" xml:space="preserve">&lt;p&gt;The doctor explained it had been a &lt;span role="definition" aria-labelledby="placebo"&gt;
&lt;dfn id="placebo"&gt;placebo&lt;/dfn&gt;, an inert preparation prescribed more for the mental relief of the patient than for its actual effect on a disorder.&lt;/span&gt;
&lt;/p&gt;</pre>
        <p>The following is an example using a definition list:</p>
        <pre class="example" xml:space="preserve">&lt;dl&gt;
 &lt;dt id="anathema"&gt;anthema&lt;/dt&gt;
 &lt;dd role="definition" aria-labelledby="anathema"&gt;a ban or curse solemnly pronounced by ecclesiastical authority and accompanied by  
excommunication&lt;/dd&gt;
 &lt;dd role="definition" aria-labelledby="anathema"&gt;a vigorous denunciation : cursor&lt;/dd&gt;
&lt;dt id="homily&gt;homily&lt;/dt&gt;
&lt;dd role="definition" aria-labelledby="homily"&gt;a usually short sermon&lt;/dd&gt;  

&lt;dd role="definition" aria-labelledby="homily"&gt;a lecture or discourse on or of a moral theme&lt;/dd&gt;

&lt;/dl&gt;</pre>
        <p>The <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#note"><code>note</code></a> role defines a parenthetic or ancillary remark to the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#main"><code>main</code></a> content of the resource. It also allows assistive technologies to skip over this section of the document unless more information is requested about the main content.</p>
        <pre class="example" xml:space="preserve">&lt;div role="main" aria-labelledby="foo"&gt;
   &lt;h1 id="foo"&gt;Wild fires spread across the San Diego Hills&lt;/h1&gt;
   Strong winds expand fires ignited by high temperatures ...
&lt;/div&gt;

&lt;div role="note"&gt;
   This article was last updated July 30, 2008 at 6:05PM. 
&lt;/div&gt;</pre>
      </div>
    </div>
  </div>
  <div class="section" id="modal_dialog">
 <h3 id="make_modal"><span class="tocnum">3.3. </span> Making a Dialog Modal</h3>
<p>
WAI-ARIA provides for two dialog roles - dialog and alertdialog. When authors simulate dialogs on a web page they often limit their interaction considerations to the mouse. Unlike Graphical User Interface dialog boxes on a desktop computer, a user during keyboard navigation could accidentally navigate outside the dialog box and become disoriented. This can happen when the user is tabbing in the dialog. A modal dialog prevents the user from setting focus outside of the dialog until the dialog is closed. Mouse clicks outside of the dialog must be ignored and the user must not be able to tab into or out of the dialog itself. All WAI-ARIA enabled dialog boxes should be modal. This section describes how. 
</p>
<p>
Mouse clicks outside of the dialog can be prevented by creating a CSS positioned element that is the size of the viewport to append as a child of the body element. Set the CSS z-index of this element so that it is above all other elements on the page except for the dialog element. Set the tabindex of the underlay element to tabindex="-1" to prevent it from receiving focus via a keyboard event or mouse click. You may lower the opacity of the underlay element in order to emphasize that the dialog itself is modal and has focus. 
</p>
<p>
Depending upon the action to be performed by the dialog, the object with focus before the dialog box is opened should be saved. This will allow restoring focus to this element when the dialog box is closed. When the dialog box is opened, focus should be set to the first tab focusable element within the dialog. If there is no tab focusable element within the dialog box contents, set the focus to the item that is used to cancel or close the dialog. There must be some element within the dialog which can accept focus in order for the screen reader to speak the dialog title and information when it is opened. In order to prevent keyboard focus from leaving the dialog, determine the first and last tab focusable elements in the dialog and trap keyboard events within the document. 
</p>
<p>
Search the contents of the dialog container to find the first and last tab focusable elements. This can be implemented by walking the DOM tree of the dialog container to find all visible and enabled anchor elements, input elements, and all elements that have a tabindex value greater than or equal to 0. Remember that elements with a tabindex &gt; 0 will appear in the tab order before all other focusable elements in ascending order by tabindex. Store the first and last tab focusable items within variables in the scope of the dialog box code. 
</p>
<p>
Before the dialog is shown, create and display the dialog underlay. Connect an onkeypress event handler to the DOM document.documentElement. This will catch all keystrokes on the document and allow trapping keyboard focus within the dialog. Size and position the dialog box in the viewport above the underlay, make it visible and set focus to the first tab focusable item in the dialog box.
</p>
<div class="section" id="trap_focus_div">
<h4 id="trap_focus"><span class="tocnum">3.3.1. </span> Trapping Focus</h4>
<p>
The onkeypress handler will catch all key presses within the document. This onkeypress event handler should be within the scope of the dialog box code so that it has access to the first and last tab focusable elements within the dialog. In the onkeypress handler determine the target of the keypress event. In addition, determine if there is only a single focusable item within the dialog box. In this instance the first tab navigable object will equal the last tab navigable object. If key presses within the dialog box may create, destroy, enable, disable, or change the visibility of tab focusable elements, then determine the first and last tab-focusable items each time a keypress is received. Based on the event target and the key pressed take the following actions:
</p>
<ul><li>
If the keypress is a <kbd>Shift+Tab</kbd> key and the target == the first tab navigable object, then set focus to the last tab-navigable object and stop the key press event. If there is only a single tab focusable item, then focus does not have to be set, but the key press event must be stopped. 
</li><li>
If the keypress is a <kbd>Tab</kbd> key and the target == the last tab navigable object, then set focus to the first tab-navigable object and stop the keypress event. If there is only a single tab-focusable item, then focus does not have to be set but the keypress event must must be stopped.
</li><li>
If the keypress is an <kbd>Esc</kbd> key and the target node is the container node for the dialog box, then close the dialog box and hide or destroy the dialog underlay.
</li></ul>
<p>
Determine if the target node of the keypress is within the dialog box container. This can be done using a while loop to walk the parent chain of the target node until the container node of the dialog box is found. Other than those outlined above, all key presses from within the dialog box should be allowed to execute so that the user can interact with the controls in the dialog box.
</p>
<p>
If the target node is not within the dialog box, the keypress is from the documentElement and the keypress event should be stopped unless it is a <kbd>Tab</kbd> key press. Allowing a <kbd>Tab</kbd> key press from the document element will enable tabbing back into the dialog box if, for some reason, focus on the dialog box is lost. This can happen due to timing issues when the dialog box is first loaded and focus does not properly get set to the first tab-focusable item within the dialog. 
</p>
<p>
The dialog box itself should contain buttons or other mechanisms to cancel the dialog box or execute the dialog box functions and close the dialog box. 
</p>
<p>
Here is a pseudo code onkeypress handler for a modal dialog box. Pseudo code is used to focus on the actions in the handler rather than on the differences in browser event handling. Assume that the event object, evt, has been normalized between browsers and the helper object is a library of functions that handle browser differences. The keys object is a set of key definition variables. Dialog is the dialog box object, which has a function to cancel the dialog. 
</p>
<pre xml:space="preserve">
_onKey: function(/*Normalized Event*/ evt){
// summary:
// Handles the keyboard events for accessibility reasons
if(evt.charOrCode){
var node = evt.target; // get the target node of the keypress event
if (evt.charOrCode === keys.TAB){
// find the first and last tab focusable items in the hierarchy of the dialog container node
// do this every time if the items may be added / removed from the the dialog may change visibility or state
var focusItemsArray = helper.getFocusItems(dialogContainerNode); 
dialog.firstFocusItem = focusItemsArray[0];
dialog.lastFocusItem = focusItemsArray[focusItemsArray.length-1];
}
// assumes firstFocusItem and lastFocusItem maintained by dialog object
var singleFocusItem = (dialog.firstFocusItem == dialog.lastFocusItem);

// see if we are shift-tabbing from first focusable item on dialog
if(node == dialog.firstFocusItem &amp;&amp; evt.shiftKey &amp;&amp; evt.charOrCode === keys.TAB){
if(!singleFocusItem){
dialog.lastFocusItem.focus(); // send focus to last item in dialog
}
helper.stopEvent(evt); //stop the tab keypress event
}
// see if we are tabbing from the last focusable item
else if(node == dialog.lastFocusItem &amp;&amp; evt.charOrCode === keys.TAB &amp;&amp; !evt.shiftKey){
if (!singleFocusItem){
dialog.firstFocusItem).focus(); // send focus to first item in dialog
}
helper.stopEvent(evt); //stop the tab keypress event
}
else{
// see if the key is for the dialog
while(node){
if(node == dialogContainerNode){ // if this is the container node of the dialog
if(evt.charOrCode == keys.ESCAPE){ // and the escape key was pressed
dialog.cancel(); // cancel the dialog
}else{
return; // just let it go
}
}
node = node.parentNode;
}
// this key is for the document window
if(evt.charOrCode !== keys.TAB){ // allow tabbing into the dialog 
helper.stopEvent(evt); //stop the event if not a tab keypress 
}
} // end of if evt.charOrCode
} // end of function
</pre>
  
  </div>
  
  </div>
</div>
<div class="section" id="relations">
  <h2><span class="tocnum">4. </span>  Relationships</h2>
  <div class="section" id="relations_labeling">
    <h3><span class="tocnum">4.1. </span>  Labeling and Describing</h3>
    <p>Marked up  content or widgets will often need additional context to make clear  what the meaning or purpose is. It is also reasonable that some content  media types will need additional descriptions in another format to give  clarity to those who are unable to consume the origin format. These  additional meta-content sections are linked together by tagging them as  labels or descriptions. WAI-ARIA provides the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> attributes to signal the browser to feed these relationships into the  accessibility layer. This layer is then used by screen readers and  other accessibility technology (AT) to gain awareness of how disparate  regions are actually contextually connected to each other. With this  awareness the AT can then present a meaningful navigation model for  discovery and presentation of these additional content sections. The  user agent itself can also choose to present these insights in a  meaningful way. Generally you should always add these attributes to any  widgets on your site as they are often merely a construct of HTML and JavaScript which provides no obvious insight as to what the widget's behavior or interactivity is. </p>
    <div class="section" id="LabeledBy">
      <h4><span class="tocnum">4.1.1. </span> Labeling</h4>
     When using one element to label another use the  <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> by attribute. A label should provide the user with the essence of what the object does. For example, you could have a dialog box erected from HTML <code>&lt;div&gt;</code> and you need to assocate a label for the dialog. With a WAI-ARIA role of dialog, you can indicate its widget type and define a label using an HTML header and then associate that label with the dialog using the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> relationship.
     <pre xml:space="preserve">
	&lt;div role="dialog" aria-labelledby="dialogheader"&gt;
	&lt;h2 id="dialogheader"&gt;Choose a File&lt;/h2&gt;
	... Dialog contents
	&lt;/div&gt;
	</pre>
      <p>The section doing the labeling might be referenced by multiple  widgets or objects as these need only reference the same id, so contextual description may not always be viable. The labelledby attribute can have multiple ids specified as a space separated list much like applying multiple classes to a single DOM object.</p>
      <p>It should be noted that (X)HTML provides a &lt;<code><a href="http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.9">label for</a></code>&gt; element which you can use to label form controls. For all visual objects, including (X)HTML form elements, you should use the WAI-ARIA <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> property for labeling. </p>
      <div class="note">
        <p class="note">Some elements receive their label for embedded text content, but that is the exception.</p>
      </div>
    </div>
    <div class="section" id="Descriptions">
      <h4><span class="tocnum">4.1.2. </span> Describing</h4>
      <div class="section" id="Descriptions_describedby">
      	<h5><span class="tocnum">4.1.2.1. </span> Using aria-describedby</h5>
      	<p>When one element  describes another, use the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> attribute. An <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> section provides further information about a given object or widget,  which may not be intuitively obvious from the context, content or other  attributes. For example, a fake window is a common widget used in Web  applications and is often constructed using a div absolute  positioned in a layer above other content. To simulate common window  behavior look and feel there is often an X box in the corner which,  when activated, dismisses the window widget. One common way to make  this X box is to simply make a link whose content is an X. This doesn't  give a non-visual user much to go on and belies the real purpose of the  X link. To help we add more descriptive text stored elsewhere in the  page like this: </p>
      	<pre class="example" xml:space="preserve"><span class="tag">&lt;button aria-label=<span class="str">"Close"</span> aria-describedby=<span class="str">"descriptionClose"</span> 
    onclick=<span class="str">"myDialog.close()"</span>&gt;</span>X<span class="tag">&lt;/button&gt;</span></pre>
      	and then elsewhere in the HTML
      	<pre class="example" xml:space="preserve"><span class="tag">&lt;div id=<span class="str">"descriptionClose"</span>&gt;</span>Closing this window will discard any information entered and 
return you back to the main page<span class="tag">&lt;/div&gt;</span></pre>
      	Like labelledby, describedby can accept multiple ids to point to other regions of the page using a space separated list. It is also limited to ids for defining these sets. In our contrived example we would also want a good labelledby  section to fully explain what the window does and how closing will  effect the task being worked on. If an object or widget lacks describedby the user agent or AT may try to extract information from the label or th tags, if present. The label and th tags have limited use in that they can only be applied to forms or tables, respectively.
      	</div>
      <div class="section" id="Descriptions_tooltip">
      	<h5><span class="tocnum">4.1.2.2. </span> Using a tooltip as a description</h5>
      	<p>WAI-ARIA also defines the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tooltip"><code>tooltip</code></a> role to which <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> may reference an author defined tooltip. The assistive  technology  can tell from the type of object describing the document  element what  the purpose of that element is. For example, a screen  reader could announce the tooltip without the user having to waive the  mouse over the element by following the describedby relationship to a  document area with a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tooltip"><code>tooltip</code></a> role. The <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> property is also useful for describing <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#group"><code>group</code></a>s. </p>
      	<p>Here is a code snippet showing a set of the tooltip: </p>
      	<pre class="example" xml:space="preserve">...    
  <span class="tag">&lt;div class=<span class="str">"text"</span>&gt;</span>
    <span class="tag">&lt;label for=<span class="str">"first"</span>&gt;</span>First Name:<span class="tag">&lt;/label&gt;</span>
      <span class="tag">&lt;input type=<span class="str">"text"</span>               
          id=<span class="str">"first"</span>           
          name=<span class="str">"first"</span>            
          size=<span class="str">"20"</span>           
          onfocus=<span class="str">"tooltipShow(tooltip1)"</span>          
          onblur=<span class="str">"tooltipHide(tooltip1)"</span>
          onmouseover=<span class="str">"tooltipShow(tooltip1)"</span>           
          onmouseout=<span class="str">"tooltipHide(tooltip1)"</span>           
          aria-describedby=<span class="str">"tp1"</span>
      /&gt;</span>
  <span class="tag">&lt;div id=<span class="str">"tp1"</span> class=<span class="str">"tooltip"</span> role=<span class="str">"tooltip"</span>&gt;</span>Your first name is optional<span class="tag">&lt;/div&gt;</span>    
  <span class="tag">&lt;/div&gt;</span>    
...  </pre>
      		</div>
    <div class="section" id="Descriptions_external">
		<h5><span class="tocnum">4.1.2.3. </span> Descriptions on external pages</h5>
    	<p>The <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> property is not designed to reference descriptions on an external resource—since it is an IDREF, it must reference an element in the same DOM document. This is different from the HTML longdesc attribute, which accepts any URI. In general, the preferred pattern for WAI-ARIA applications is to include all relevant resources in the same DOM, But if you wish to reference an external resource with <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a>, you can reference a link that in turn references the external resource. This requires the user to follow two steps, first following the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> arc, then following the link, but does address the use case. The following example demonstrates this:</p>
    	<pre class="example" xml:space="preserve"><span class="tag">&lt;p&gt;</span>
   <span class="tag">&lt;img
       src=<span class="str">"images/histogram.png"</span>
       alt=<span class="str">"Histogram of Blackberry tree heights"</span>
       width=<span class="str">"40%"</span>
       aria-describedby=<span class="str">"longdesc1"</span>
   /&gt;</span>
<span class="tag">&lt;/p&gt;</span>

<span class="tag">&lt;p&gt;</span>
    <span class="tag">&lt;a id=<span class="str">"longdesc1"</span> href=<span class="str">"blackberry-description.html"</span> target=<span class="str">"_description"</span>&gt;</span>Data for Blackberry Histogram<span class="tag">&lt;/a&gt;</span>
<span class="tag">&lt;/p&gt;</span></pre>
    </div>
    </div>
  </div>
  <div class="section" id="relations_owning">
    <h3><span class="tocnum">4.2. </span>  Owning and Controlling</h3>
    <p>Two relationships expand the logical structure  of a WAI-ARIA Web application. These are <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> .  The <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> relationship completes the parent/child relationship when it cannot be completely determined from the DOM created from the parsing of the markup. The <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> relationship defines a cause-and-effect relationship so that assistive technologies may navigate to content effected by and changes to the content where the user is operating. </p>
    <div class="section" id="relations_owns">
      <h4><span class="tocnum">4.2.1. </span>  The Owns Relationship</h4>
      <p>In addition to WAI-ARIA role and state information, for a document element,
an assistive technology needs to convey its context. In
the case of a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treeitem"><code>treeitem</code></a>, it is important to know the parent (container),
 which may provide a folder depth and the number of siblings in the folder. This containment hierarchy can often be determined by
the DOM tree, as it provides parent, siblings, and children for a given
document element. That said, the DOM hierarchy is rigid and acyclical in
that each node may only have one parent. In some situations, a child
is reused by multiple parents or a child is separated from its
sibilings or parent in the DOM tree. One example is when a radio button
appears in a table but it is not a DOM child of the radiogroup, due to the
authors use of a table for formatting and the placement of the radio buttons
placing them outside the radiogroup container. To solve this problem
WAI-ARIA provides the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> property.</p>
<p>
The <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> property is set on a document element, and its values are the
unique IDs of all the adopted children. These elements may appear anywhere
in the DOM, yet they are treated as siblings of each owning parent. This
example illustrates a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#radiogroup"><code>radiogroup</code></a> that first uses the DOM hierarchy to
convey context and then <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a>:</p>
<p>First, consider the preferred method for using the W3C DOM to describe the relationship between
  <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#radiogroup"><code>radiogroup</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#radio"><code>radio</code></a>  roles for HTML:</p>
<pre xml:space="preserve">
&lt;div id="radio_label"&gt;My radio label&lt;/div&gt;
&lt;ul role="radiogroup" aria-labelledby="radio_label"&gt;
&lt;li role="radio"&gt;Item #1&lt;/li&gt;
&lt;li role="radio"&gt;Item #2&lt;/li&gt;
&lt;li role="radio"&gt;Item #3&lt;/li&gt;
&lt;/ul&gt;
</pre>
<p>
In this example, the elements with <code>role="radio"</code> are child nodes of the parent <code>role="radiogroup"</code> element node.

</p>
<p>
Now, consider an alternative method using the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> property to describe the parent-child
role relationship between <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#radiogroup"><code>radiogroup</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#radio"><code>radio</code></a> roles for HTML:</p>
<pre xml:space="preserve">
&lt;table&gt;
&lt;tr&gt;
&lt;td role="radiogroup" aria-owns="myradio1 myradio2 myradio3" rowspan="3" &gt;
My Radio Label
&lt;/td&gt;
&lt;td id="myradio1" role="radio"&gt;Item #1&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td id="myradio2" role="radio"&gt;Item #2&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td id="myradio3" role="radio"&gt;Item #3&lt;/td&gt;
&lt;/tr&gt;
&lt;/table&gt;
</pre>
<p class="note">
The <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> property should be used sparingly, since it
increases the computational load on assistive technology to provide
alternative renderings. Also, when accessing the DOM and enumerating
children of a DOM node, an AT should then enumerate the adopted children
using the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> property. At that instance of walking the DOM, the
parent of the adopted children is the adopted parent and not the DOM
parent. This will avoid recursion problems.</p>
<p>
Each child, adopted or natural, should have the appropriate
  <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-posinset"><code>aria-posinset</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-setsize"><code>aria-setsize</code></a> properties set consistent with their
rendering, if these cannot be determined from the DOM from a direct parsing of
the host language. Places where direct parsing does not allow the user
agent to determine 
  <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-posinset"><code>aria-posinset</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-setsize"><code>aria-setsize</code></a>  are long lists where only
the currently visible items are loaded (via Ajax). If the children are
re-sorted then the 
  <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-posinset"><code>aria-posinset</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-setsize"><code>aria-setsize</code></a>  values should be updated
consistent with their visual rendering. Rather than setting  size only on a container, content authors should specify aria-setsize on each  member of a set to avoid performance issues.  If this property is not set,  the user agent must compute and set the property on supporting roles.</p>
<p> Platform accessibility API mappings must invert this relationship for
  assistive technologies, so that they may determine the owning parent from a
  child and couple it with <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-posinset"><code>aria-posinset</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-setsize"><code>aria-setsize</code></a>  information to
  provide context information to the user.</p>
    </div>
    <div class="section" id="relations_owns_reuse">
      <h4><span class="tocnum">4.2.2. </span>   Using Owns with Reusable Content</h4>
      <p>If  you are re-using content across different, transient  sections of content by restyling it to render it in association with a different object, you need to maintain the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> property   as well to match the current use and apparent ancestry of the reused  sub-section. A good example of this is a context help menu that resides at the end of the document. When the user wishes to launch the context help menu in association with different visual elements, styling is used to render the menu in context with that object. Prior to rendering the visual submenu you should ensure the object to which you have requested help assigns its <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> property value to the submenu ID. When the menu closes you can remove the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> property. </p>
    </div>
    <div class="section" id="relations_controls">
      <h4><span class="tocnum">4.2.3. </span>  The Controls Relationship</h4>
      <p>In rich internet applications document elements may control the behavior on another part of Web page outside themselves. The <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> attribute indicates cause-and-effect relationships between document  elements. </p>
      <p>An example might be a group of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#radio"><code>radio</code></a> buttons that "control" contents of a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listbox"><code>listbox</code></a> in another part of the page. Here, you would want the radio group to assign a <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> relationship to the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listbox"><code>listbox</code></a> which will be updating without a page reload. The user, through their assistive technology, can then navigate to the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listbox"><code>listbox</code></a> by following the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> relationship when a different radio is selected, to see how the contents changed in the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listbox"><code>listbox</code></a>. The ability to update parts of a page without a page reload is a common practice of applications making use of Ajax. Without the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> attribute, a user would be unable to effectively use these types of Web pages as assistive technologies often will not make the user aware of what is happening outside the context of the element the user is currently operating.</p>
      <p>With the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> attribute the user may use the assistive technology to follow the relationship to the object it is controlling. It is extremely important for an assistive technology to present changes in the document in response to user input. Therefore, an assistive technology immediately presents changes to a live region when the controlling widget is the one which has user keyboard focus. For example, if a tree view controls a help document pane, each time<br clear="none"/>
        the tree item changes the new tree item and then the new help contents should also be read. In the case of a screen reader, the amount of information  read in the target live region is dependent on <a href="#liveprops">how the live region is configured</a>. </p>
      <p>The <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> attribute takes one or more ids which refer to the document element. If this relationship is not implied by the host  language semantics, then the controlling element must be given a controls attribute with the IDs of the other elements where the changes will  show up listed in the attribute value.</p>
    </div>
  </div>
  <div class="section" id="relations_flowto">
    <h3><span class="tocnum">4.3. </span>  Changing the Reading Flow</h3>
    <p>(X)HTML suffers from a number of disadvantages in  keyboard navigation today. One such example is the restriction of  navigation to the tabbing order. This is a common problem with  presentations in office suites where the logical, perceivable,  navigation order of a slide may not match the tabbing order. Sighted  users may see a logical navigation process (such as visual steps in the  process for assembling a lawn mower). This "flow" is not conveyed by  the tab order. The user might tab from step 1 and land on step 4.  Another problem is the construction of model-based authoring tools on a  Web page. In a model-based authoring tool, a visual object may provide  a number of paths that the user can take, such as a multiplexor, which  may have output that logically flows to a number of optional electronic  components in a drawing. In Web 2.0, developers are actually creating  drawings like this to perform tasks such as visually model a work flow.  In this scenario, the user will want to decide which object they will  navigate their screen reader or alternate input device to next. </p>
    <p>Although it is  recommended that Tab order follow the reading flow, there may be instances  where this is not possible. For these reasons, WAI-ARIA provides a relationship property, called <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-flowto"><code>aria-flowto</code></a>. This allows the author to provide an assistive technology with alternative navigation flows through the document that best represents the author's intent and which is more logical for people with disabilities. <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-flowto"><code>aria-flowto</code></a> establishes the recommended reading order of content, so that the an assistive may overriding the default of reading in document order to its user. <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-flowto"><code>aria-flowto</code></a> does not change the keyboard navigation order of they browser.</p>
    <p>Consider  the first case of changing a basic reading flow to circumvent(X)HTML  tabbing. A good example of this is a logical reading flow in a portal  with landmarks. In the future, the user may wish to change the reading  flow based on the order of priority with which they navigate a  personalized Web application like <a href="http://www.myspace.com/">MySpace</a> or <a href="http://my.yahoo.com/">MyYahoo</a>.  In the following example, the navigation would follow the order of "Top  News Stories", "television listings", "stock quotes", and "messages  from friends" by following (X)HTML document reading order. However, the  author or end user may determine that the main content is most  important, followed by "stock quotes", "messages from friends", and  then "TV listings."</p>
    <pre class="example" xml:space="preserve">&lt;html&gt;  
...  
&lt;div role="main" title="Top News Stories" id="main" aria-flowto="stock"&gt;&lt;/div&gt;  
&lt;div role="complementary" title="television listings" id="tv"&gt;&lt;/div&gt;
&lt;div role="complementary" title="stock quotes" id="stock" aria-flowto="messages"&gt;&lt;/div&gt;
&lt;div role="complementary" title="messages from friends" id="messages" aria-flowto="tv"&gt;&lt;/div&gt;  </pre>
    <p>The  second use case is such that the Web developer may wish to circumvent  the flow by branching to multiple paths in the Web page, requiring the  assistive technology to present a collection of options where the user  could go next. This is important for work flows or business process  management applications as shown in this <a href="http://www.skelta.com/products/screenshot-gallery/screens.aspx#ProcessDesigner">Process Designer Tool</a>.  More of these applications are becoming Web based, and a vehicle is  required to tell the user how to get through the work flow. The flowto  property takes multiple idrefs, allowing the author to define each  object the user could flow to. To implement this technique do the  following. </p>
    <ul><li>
        <p><a id="step1_obj_accessible" name="step1_obj_accessible"></a>Make each object in the work flow accessible</p>
        <p>This  will require assigning a title or WAI-ARIA label for each object and a  unique HTML id. Also, if the html element is repurposed assign it a  WAI-ARIA role. </p>
        <pre class="example" xml:space="preserve">&lt;html&gt;

...  
&lt;img src="foo.jpg" id="331" title="What is the Invoice Value?"&gt;  
&lt;img src="foo.jpg" id="333" title="Finance Manager Approval"&gt;  
&lt;img src="foo.jpg" id="334" title="Sales Manager Approval"&gt;  
...  </pre>
      </li><li><a id="step2_flowto" name="step2_flowto"></a>Assign the flowto properties
        <p>For each visual object that will flow to one or more other objects assign  the flowto property the list of IDs to which it flows. </p>
        <pre class="example" xml:space="preserve">&lt;html&gt;  
...  
&lt;img src="foo.jpg" id="331" title="What is the Invoice Value?" aria-flowto="333 334"&gt;  
&lt;img src="foo.jpg" id="333" title="Finance Manager Approval"&gt;  
&lt;img src="foo.jpg" id="334" title="Sales Manager Approval"&gt;  
...  </pre>
<p>Each element referenced by the flowto must have have a unique id. The combination of the unique id and the name allow the assistive technology  to adequately assist the user in retracing their steps backward through a flow to reference or moving forward to it. Since the author sets only the target the user agent is responsible for mapping the backward reference relationship. Therefore, neither the user agent nor the user can get lost. The host user agent does not provide an alternative navigation order; this is an assistive technology function.</p>
      </li><li><a id="step3_keyboard" name="step3_keyboard"></a>Make sure visual objects are keyboard accessible
        <p>Use tabindex to enable objects to receive focus. Actually setting focus to them may be performed by an assistive technology, such as an alternative input device. This example places each drawing object in  document order with respect to the tab sequence. </p>
        <pre class="example" xml:space="preserve">&lt;img src="foo.jpg" id="331" title="What is the Invoice Value?"
    aria-flowto="333 334" tabindex="0"&gt;
&lt;img src="foo.jpg" id="333"  title="Finance Manager Approval" tabindex="0"&gt;
&lt;img src="foo.jpg" id="334" title="Sales Manager Approval" tabindex="0"&gt;
...  </pre>
        <p>When  an assistive technology encounters "What is the Invoice Value?," it  will know to tell the user that they may choose to navigate either to  the "Financial Manager Approval" or to the "Sales Manager Approval"  object. The options may be provided through a menu for the What is the Invoice Value object by the assistive technology. After a choice  is made, then the AT can  move focus to the target object; or in  the case of a screen reader, it may just move the user to that location  in the screen reader's virtual buffer. </p>
        <p>Note:  WAI-ARIA does not specify backward flowto properties for the same reason  that we do not have the reverse of relationships like labelledby. The  author may incorrectly do the reversal, creating a whole set of new  problems. Rather, the task of the reversal relationships may be handled  by the user agent through its accessibility API mapping or in the  assistive technology itself.</p>
      </li></ul>
    </div>
	<div class="section" id="relations_haspopup">
		<h3><span class="tocnum">4.4. </span> Popups and drop-downs</h3>
		<p>In order for menus, menubars, and menuitems to indicate that it opens a menu, set its <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-haspopup"><code>aria-haspopup</code></a> property to "true." The type of menu being launched (submenu, context help, etc.) is not explicitly indicated with WAI-ARIA but is based on the operational characteristics (keyboard and mouse commands). </p>
		<p>Combo boxes, or drop down lists, work differently. Controls with the role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#combobox"><code>combobox</code></a> must contain a list of items that can be opened, usually as a drop-down. Because this is intrinsic to the functioanlity of a combo box, it does not need to be explicitly indicated with <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-haspopup"><code>aria-haspopup</code></a>.</p>
		
		<p>The following html fragment shows the use of <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-haspopup"><code>aria-haspopup</code></a> with a menubar, its menus, and submenus. All of the menuitems associated with the menubar have <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-haspopup"><code>aria-haspopup</code></a> set to 'true'. Also, the "Zoom" menuitem of the "View" menu has an <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-haspopup"><code>aria-haspopup</code></a> property as it leads to a submenu.</p>
		
		<pre class="example" xml:space="preserve"><span class="tag">&lt;div role=<span class="str">"menubar"</span>&gt;</span>
  <span class="comment">&lt;!--
    File menu: File menuitem has an aria-haspopup attribute set to 'true'.
    That popup div follows immediately below.
  --&gt;</span>
  <span class="tag">&lt;div role=<span class="str">"menuitem"</span> <em>aria-haspopup=<span class="str">"true"</span></em> id=<span class="str">"fileMenu"</span>&gt;</span>File<span class="tag">&lt;/div&gt;</span>
  <span class="tag">&lt;div role=<span class="str">"menu"</span> aria-labelledby=<span class="str">"fileMenu"</span>&gt;</span>
    <span class="tag">&lt;div role=<span class="str">"menuitem"</span>&gt;</span>Open<span class="tag">&lt;/div&gt;</span>
    <span class="tag">&lt;div role=<span class="str">"menuitem"</span>&gt;</span>Save<span class="tag">&lt;/div&gt;</span>
    <span class="tag">&lt;div role=<span class="str">"menuitem"</span>&gt;</span>Save as ...<span class="tag">&lt;/div&gt;</span>
    ...
  <span class="tag">&lt;/div&gt;</span>
  <span class="comment">&lt;!--
    View menu:
  --&gt;</span>  
  <span class="tag">&lt;div role=<span class="str">"menuitem"</span> <em>aria-haspopup=<span class="str">"true"</span></em> id=<span class="str">"viewMenu"</span>&gt;</span>View<span class="tag">&lt;/div&gt;</span>
  <span class="tag">&lt;div role=<span class="str">"menu"</span> aria-labelledby=<span class="str">"viewMenu"</span>&gt;</span>
    <span class="tag">&lt;div role=<span class="str">"menuitem"</span>&gt;</span>Normal<span class="tag">&lt;/div&gt;</span>
    <span class="tag">&lt;div role=<span class="str">"menuitem"</span>&gt;</span>Outline<span class="tag">&lt;/div&gt;</span>
    <span class="comment">&lt;!--
      The View's Zoom menuitem has aria-haspopup='true' as it leads to a
      submenu.
    --&gt;</span>
    <span class="tag">&lt;div role=<span class="str">"menuitem"</span> <em>aria-haspopup=<span class="str">"true"</span></em> id=<span class="str">"zoomSubMenu"</span>&gt;</span>Zoom<span class="tag">&lt;/div&gt;</span>
    <span class="tag">&lt;div role=<span class="str">"menu"</span> aria-labelledby=<span class="str">"zoomSubMenu"</span>&gt;</span>
      <span class="tag">&lt;div role=<span class="str">"menuitem"</span>&gt;</span>50%<span class="tag">&lt;/div&gt;</span>
      <span class="tag">&lt;div role=<span class="str">"menuitem"</span>&gt;</span>75%<span class="tag">&lt;/div&gt;</span>
      <span class="tag">&lt;div role=<span class="str">"menuitem"</span>&gt;</span>100%<span class="tag">&lt;/div&gt;</span>
      <span class="tag">&lt;div role=<span class="str">"menuitem"</span>&gt;</span>150%<span class="tag">&lt;/div&gt;</span>
      <span class="tag">&lt;div role=<span class="str">"menuitem"</span>&gt;</span>200%<span class="tag">&lt;/div&gt;</span>
    <span class="tag">&lt;/div&gt;</span>
  <span class="tag">&lt;/div&gt;</span>
<span class="tag">&lt;/div&gt;</span></pre>
	</div>
</div>
<div class="section" id="docmgt">
  <h2><span class="tocnum">5. </span> Managing Dynamic Changes</h2>
  <div class="section" id="ContentPresChanges">
    <h3><span class="tocnum">5.1. </span>  Managing Content and Presentational Changes </h3>
    <p>General rules for managing content and displaying information</p>
    <ul><li>Do not change an element's role once it has been set. If you need to change the role of an object, first remove the element from the DOM tree and then add the new element to the tree with the new role set. </li><li>For supporting browsers, tie CSS attribute selectors to WAI-ARIA properties to reduce script (browser issue with refresh).</li><li>Tie CSS <code>display</code> property to WAI-ARIA hidden state. This is important for assistive technologies who communicate directly with the user agent's DOM versus a platform accessibility API supported by the user agent. You can also tie <a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/visufx.html#visibility">CSS <code>visibility:hidden</code></a> or <code><a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/visufx.html#visibility">visibility:collapse</a></code> to the WAI-ARIA hidden state but the use of <code><a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/visufx.html#visibility">visibility:hidden</a></code> will affect layout in that content will continue to flow around the hidden area even though the content to be hidden is invisible. </li></ul>
    <p>If you are refreshing areas asynchronously, then you need to designate live regions. The following sections explain how to implement live regions and when to use roles that are considered "live" sections by default, including alert, status, or log.</p>
  </div>
  <div class="section" id="LiveRegions">
    <h3><span class="tocnum">5.2. </span>  Implementing Live Regions </h3>
    <p><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#attrs_liveregions">Live regions</a> are parts of a Web page that the author expects to change.  Examples of live regions include tables with dynamically updated  content (sports stats, stock information), logs where new information  is being added (chat transcript logs), notification areas (status,  alerts), etc. </p>
    <p>Live  regions enable assistive technologies, such as screen readers, to be  informed of updates without losing the users' place in the content.  Live region settings provide hints to assistive technologies about how  to process updates. Note that the assistive technology is responsible  for handling these updates and enabling users to override these hints. </p>
    <p>The section on <a href="#liveprops">Live Region Properties</a> and how to use them gives the details of how to apply live region properties. This  process will help rich internet application (RIA) developers to set  live region settings that will provide a good user experience for  most assistive technology users with little configuration on their  part. When applying these live region properties, it is recommended that you conduct user testing. If the <acronym title="assistive technology">AT</acronym> supports scripting of the response to live regions you may wish to customize the response, such as through a screen reader script for your Web page.</p>
    <ol><li>
        <p><strong>Identify the live regions</strong></p>
        <p>Live regions are any region on a page that receives dynamic updates through client-side scripting. Note the regions of your page that will be live. </p>
      </li><li>
        <p><strong>See if any of the special case live regions meet your needs</strong></p>
        <p> WAI-ARIA provides a number of <a href="#chobet">special case live region roles</a> whose live region properties are pre-defined and which you may use. If one of these live region roles meet your needs just apply the specific role to the region of the Web page.</p>
      </li><li>
        <p><strong>Decide the priority of each live region</strong></p>
        <p>When a live  region changes, should the user be notified of the change?  Notifications could include a sound for a screen reader user. (For  simplicity, we will use the case of an audio notification in this  discussion.) The shorter the interval between changes and the less  important the information, the less likely that the user needs to hear  every change. A simple example of changes that should not be heard are  changes to time; a sound for every second would be very annoying. </p>
        <p>If  the user should hear the change, should the change be announced  immediately, as soon as possible, or only when the user is idle?  Announcing a change immediately can be disorienting for users, so that  should be done sparingly. Most updates should probably only be  announced when the user is idle. </p>
        <p>After you have decided the priority for each live region, then decide the <em>live</em> property value: </p>
        <ul><li>Never spoken, then <code><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-live"><code>aria-live</code></a>="off"</code> </li><li>Spoken when user is idle, then <code><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-live"><code>aria-live</code></a>="polite" </code></li><li>Spoken as soon as possible, then <code><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-live"><code>aria-live</code></a>="assertive"</code> </li><li>For more specifics, see <a href="#liveprops" title="Live Region Properties">Live Region Properties</a>.</li></ul>
      </li><li>
        <p><strong>Decide how much context is needed for each update</strong></p>
        <p>When part  of a live region changes, how much context is needed to understand the  change. Does the user need to hear the entire live region or just the  change by itself? </p>
        <p>If the user needs to hear the entire live region, then mark the entire live region with <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-atomic"><code>aria-atomic</code></a>="true". </p>
      </li><li>
        <p><strong>Decide what types of changes are relevant for each live region</strong></p>
        <p>Three possible types of changes are: additions, removals, and text. <em>Additions</em> means new nodes are added to the DOM; <em>removals</em> means nodes are removed from the DOM; and <em>text</em> means changes are solely to the textual content. Should the user hear all types of changes or only certain types? </p>
        <p>By  default, the user will hear additions and text type changes. If you  wish to explicitly define the types of changes, you need to set  relevant="THE_TYPES_OF_CHANGES". If more than one type of change is  relevant, the types are separated by a space. For example, to define  additions and removals as relevant but not text, set  relevant="additions removals". </p>
      </li></ol>
    <div class="section" id="liveprops">
      <h4><span class="tocnum">5.2.1. </span>  Live Region Properties and How to Use Them</h4>
      <p>One of the  most important concepts behind live regions is politeness. Politeness  indicates how much priority a live region has. The following politeness values are available for <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-live"><code>aria-live</code></a>: off, polite, and assertive.</p>
      <dl><dt><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-live"><code>aria-live</code></a>="off"</dt><dd>This is the  default. Any updates made to this region must not be announced to the  user. live="off" would be a sensible setting for things that update  very frequently such as GPS coordinates of a moving vehicle.</dd><dt><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-live"><code>aria-live</code></a>="polite"</dt><dd>Any updates  made to this region should only be announced if the user is not  currently doing anything. live="polite" should be used in most  situations involving live regions that present new information to  users, such as updating news headlines.</dd><dt><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-live"><code>aria-live</code></a>="assertive"</dt><dd>Any updates  made to this region are important enough to be announced to the user as  soon as possible, but it is not necessary to immediately interrupt the  user. live="assertive" must be used if there is information that a  user must know about right away, for example, warning messages in a  form that does validation on the fly.</dd></dl>
      <p>There are times to suppress AT presentation changes while a region is updating. For that you can use the <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-busy"><code>aria-busy</code> (state)</a> property.</p>
      <dl><dt><a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-busy"><code>aria-busy</code> (state)</a>="true"</dt><dd>
          <p>To suppress presentation of changes until a region is finished updating or until a number of rapid-fire changes are finished, set <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-busy"><code>aria-busy</code> (state)</a>="true" and then clear the attribute when the region is finished. While it is busy, the AT will track and collate the changes. It will finally speak the changes once the region is no longer busy.</p>
        </dd></dl>
      <p>When a live  region is updated, the update can often be announced on its own and  still make sense. For example, if a news headline is added, it would  make sense to simply announce the headline. However, sometimes the  entire live region must be read in order to give the user enough  context to make sense of the update. For example, it would not make  sense to only give the current value of a stock without saying the name  of the stock. The atomic setting gives assistive technologies a hint  about which of these cases an update falls into. </p>
      <dl><dt><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-atomic"><code>aria-atomic</code></a>="false"</dt><dd>This is the  default. It means that when there is a change in the region, that  change can be presented on its own; the AT should not present the  entire region. atomic="false" is generally a good idea as it presents  users with only changes and does not cause them to hear repetitive  information that has not changed. However, Web developers should take  care that the changed information, when presented by itself, can still  be understood and contextualized by the user. </dd><dt><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-atomic"><code>aria-atomic</code></a>="true"</dt><dd>If atomic  is set to "true", it means that the region must be presented as a  whole; when there is a change, the AT should present the entire region,  not just the change. atomic="true" can make it harder for users to  understand changes as the changed areas are not presented  independently. atomic="true" can also be annoying as it can force users  to listen to repetitive information that has not changed. However,  atomic="true" is necessary in cases where the change, when presented by  itself, cannot be understood and contextualized by the user. Note that when aria-atomic="true", the AT will attempt to speak the atomic region only once when multiple changes occur in the same region and it hasn't been spoken yet. </dd></dl>
      Not all  updates to a live region are relevant. For example, if the oldest  headline in a list of headlines is removed and a new headline is added,  the removal of the oldest headline is probably not important enough to  announce to the user. However, in a chat application, when a user  leaves the chat and their username is removed from the list of users,  that removal may be important enough to announce. The relevant setting  gives a hint about what types of changes are relevant and should be  announced. Any change which is not relevant will be treated as if the  region had live="off" and will not be announced. Multiple types of  changes can be listed as relevant; the types are separated by a space.  The default is relevant="additions text" and this is the most common use case. If the default is applicable to your application, you do not need to provide the relevant property explicitly.
      <dl><dt><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-relevant"><code>aria-relevant</code></a>="additions"</dt><dd>Insertion of nodes to the live region should be considered relevant. </dd><dt><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-relevant"><code>aria-relevant</code></a>="removals"</dt><dd>Removal of nodes to the live region should be considered relevant. 
          Often, removals are not relevant because nodes are removed to make space for new information - e.g. a log implemented as a table where items are taken off the top. However, in the case of something like a buddy list, it is relevant if a buddy is removed. It doesn't require the screen reader to speak the removal, but it notifies the screen reader that it could be useful to do so. Use of <code>aria-relevant="removals"</code> or <code>aria-relevant="all"</code> should be used sparingly. Notification of an assistive technology when content is removed may cause an unwarranted number of changes to be notified to the user. </dd><dt><a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-relevant"><code>aria-relevant</code></a>="text"</dt><dd>Changes to the textual content of nodes that already exist  in the live region should be considered relevant. Textual content  includes text equivalents, such as the alt attribute of images. </dd></dl>
      <p> This example shows two live regions. If both regions update  simultaneously, liveRegionA should be spoken first because its message has a  higher priority than liveRegionB.      </p>
      <blockquote>
        <pre class="example" xml:space="preserve">&lt;div id="liveRegionA" aria-live="assertive"&gt;         
&lt;/div&gt;         
&lt;div id="liveRegionB" aria-live="polite&gt;         
&lt;/div&gt;</pre>
      </blockquote>
    </div>
  </div>
  <div class="section" id="chobet">
    <h3><span class="tocnum">5.3. </span>  Choosing Between Special Case Live Regions</h3>
    <p>You may wish to use a special live region role instead of applying live region properties. WAI-ARIA contains a number of standard roles which are by default considered "live" sections of your Web page. It is important to know when to use these and when to create a custom live region on your known. Here are some rules of thumb:</p>
    <blockquote>
      <p><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alert"><code>alert</code></a> - You must use the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alert"><code>alert</code></a> role for  a one-time notification which shows for a period of time and goes away and is intended to alert the user that something has happened. The assistive technology should be notified by the user agent  that an alert has occurred, if your operating system supports this type of event notification. When choosing to use alert you should use the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alertdialog"><code>alertdialog</code></a> role instead if  something inside the alert is to receive focus. Both <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alert"><code>alert</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alertdialog"><code>alertdialog</code></a> appear to pop-up to the user to get their attention.</p>
      <p><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#status"><code>status</code></a> - You must use the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#status"><code>status</code></a> role when you want to mark an area which is updated periodically and provides general status of your Web application. Changes in status are not typically announced automatically by an assistive technology. However, it is possible to configure some assistive technologies, such as a scriptable screen reader, to watch for changes in the status bar and announce them.  Using the status role is also important in that the user could always check the status section for changes in status on different Web pages. Many applications provide status widgets and they are often found, visibly, at the bottom of the application and contain a variety of widgets within it to convey status. The use of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#status"><code>status</code></a> does not guarantee how the AT will respond to changes in the status. The author can still put live="off" or live="assertive" to influence the ATs treatment of the status. </p>
      <p><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#timer"><code>timer</code></a> - You must use a timer role when you want to mark an area which indicates an amount of elapsed time from a start  point, or the time remaining until an end point. The text encapsulated within the timer indicates the current time  measurement, and are updated as that amount changes. However, the timer value is not necessarily machine parsable.  The text contents <strong>MUST</strong> be updated at fixed intervals, except when the timer is paused or reaches an  end-point. </p>
      <p><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#marquee"><code>marquee</code></a>- You must use a marquee role when you need to mark an area with scrolling text such as a stock ticker. The latest text of the scrolled area must be available in the DOM. A marquee behaves like a <a href="#liveprops">live region</a>, with an assumed default <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-live"><code>aria-live</code></a> property value of "polite."</p>
      <p><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#log"><code>log</code></a> - You must use log if you have a live area where new information is added, like a scrolling chat log of text. Unlike other regions, implied semantics indicate the arrival of new items and the reading order. The log  contains a meaningful sequence and new information is added only to the  end of the log, not at arbitrary points. If you have a chat text entry area you should indicate that it also controls the aria log aria like so:</p>
      <pre class="example" xml:space="preserve">&lt;div contenteditable="true" role="log" id="chatlog"&gt;
&lt;/div&gt;


&lt;label id="gettext"&gt;Send Text&lt;/label&gt;
&lt;div aria-controls="chatlog" 
     role="textbox" 
     contenteditable="true" 
     aria-labelledby="gettext"&gt;
&lt;/div</pre>
        <p><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#attrs_liveregions">live region</a> - If you have some other live area use case, WAI-ARIA allows you to mark an area using the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-live"><code>aria-live</code></a> attribute. This accompanied by the collection of attributes which support the live property allow you to create your own custom live area on your Web page. For more details regarding live regions refer to the <a href="#LiveRegions">live region</a> section of this guide.</p>
    </blockquote>
  </div>
</div>
<div class="section" id="ariaform">
<h2><span class="tocnum">6. </span> Form Properties</h2>
<p>
This section identifies authoring practices for elements used as form elements.
</p>
<div id="use_invalid">
<h3 id="useinvalid">Use aria-invalid and aria-required To Improve Access to Forms</h3>
<p>
Until the introduction of WAI-ARIA's aria-invalid state and aria-required property, only presentational strategies have been available to Web content authors to indicate that certain form fields and controls are required or invalid. In applications, these states are only available through styling or varying markup, which is inconsistent, and therefore is inconclusive. In Web-based forms, fields required may be marked by an asterisk. Forms submitted with required data missing or improperly specified may be redisplayed with the unacceptable elements highlighted in red. The assistive technology user is poorly served by such imprecise methods, and all users confront inconsistent indicators for consistent situations.
</p>
<p>
The WAI-ARIA invalid state and required property provide:
</p>
<ul><li>
A programmatic aria-required property that can be applied to a form element to indicate to an AT that it is required to complete the form.
</li><li>
A programmatic aria-invalid state that can be used to indicate which data fields have incorrect data to an AT so that the user knows they have entered invalid data. Invalid data is often rendered in red by HTML form developers.
</li></ul>
<h3 id="alertmax">Alert the User When Maximum Length Value Is Reached</h3>
<p>When a text input field that has a maximum length value (or the host markup language's equivalent) receives focus, the value defined for 
"maximum length" should be communicated to the user. When text entry reaches that maximum length (or the markup language's equivalent), an alert (expressed in accordance with user preferences and capabilities) should inform the user that the maximum length for a given field has been reached. Such an alert can be expressed programmatically or, using as an aural icon, by using a WAI-ARIA alert; the user agent may alert the user through a system beep and by triggering the operating systems' "show sounds" facility. When maximum length (or the markup language's equivalent) is reached, the user must then be able to move to another form field in a manner consistent with tab-navigation for that document.</p>
</div>
<div id="focus_change">
<h3 id="auto_focus_change">Automatic Focus Changes</h3>
<p>Having a user agent automatically change focus in a form in response to user input can be advantageous in situations where that change saves the user keystrokes or on-screen keyboard interaction in order to manually move the focus from one field to another. However, as with form auto-completion, this type of text input event must be firmly under user control because this may not have been the user's intention and some users with disabilities may become disoriented such as those with sight impairments. Consider these cases:</p>
<ul><li>For a text input field that automatically moves focus to a new 
field when the value defined for "maximum length" (or the markup language's 
equivalent) is reached, the user must have the ability to suppress the change in focus. Otherwise, the user's assistive
technology may not be able to make the user aware of the error.</li><li>
A textarea field that has a scripted counter to display the number 
of characters entered or the number of characters available for input; 
in this case, the dynamic content (the character count) must be owned 
by the textarea as a live region, so that the user can keep either a 
running (real-time) account of how many characters are left for him 
to input or can obtain such information on user query.</li></ul>
</div>
<div id="autosubmit">
<h3 id="form_autosubmit">Form Auto-submit</h3>
<p>Use caution when using automatic submission of a form without explicit user command or 
in response to a user-defined setting that permits such behavior, as 
expressed by the Priority 1 <acronym title="User Agent Accessibility Guidelines 1.0">UAAG 1.0</acronym> Checkpoints 
  <a href="http://www.w3.org/TR/UAAG10/guidelines.html#tech-selection-focus-conventions">7.1</a>, 
  <a href="http://www.w3.org/TR/UAAG10/guidelines.html#tech-default-input-sensible">7.2</a> and 
  <a href="http://www.w3.org/TR/UAAG10/guidelines.html#tech-info-current-ua-config">11.1</a>. 
Unless the user has specifically chosen to set the user agent to allow auto-submission, authors are advised not to set onChange or onFocus events either to trigger submission of a form or to provide an auto-submission event upon 
completion of all or all required fields of a form or input 
field. </p>

</div>

</div>
<div class="section" id="math">
	<h2><span class="tocnum">7. </span> Math</h2>
	<p class="ednote">Editors' note: This section was added as part of disposition of comment 4, but is very incomplete. The section needs to be reordered, so that instructions on how to use the math role properly appear before considerations of legacy content and negative examples (such as the use of generic HTML to approximate a visual representation of a mathmatical expression). It needs more introductory text about how to use math. The examples need better introductions, and the positive examples should preceded the negative examples, which need to be explained more fully.</p>
	<p>There exists significant amounts of legacy content that uses images 
		and/or textual approximations to represent mathematical expressions. 
		Examples of this include the use of ASCII art and/or the misuse of 
		HTML tags -- in particular, SUB and SUP -- to achieve a visual 
		approximation of a mathematical expression, one which is void of 
		the structure needed to render mathematical expressions inherently 
	meaningful.</p>
	<p>Use of generic HTML to approximate a visual rendering
	of a mathematical expression:</p>
	<p><code class="example">&lt;i&gt;a&lt;/i&gt;&lt;i&gt;x&lt;/i&gt;&lt;sup&gt;2&lt;/sup&gt; + &lt;i&gt;b&lt;/i&gt;&lt;i&gt;x&lt;/i&gt; + &lt;i&gt;c&lt;/i&gt; = 0</code> </p>
	<p>Accessible example of the same function, using the math role, appropriate label, and MathML rendering:</p>
	<pre class="example" xml:space="preserve">&lt;div role="math" aria-label="a times x squared plus b times x plus c equals 0"&gt;
  &lt;math xmlns='http://www.w3.org/1998/Math/MathML'&gt;
    &lt;mrow&gt;
      &lt;mrow&gt;
         &lt;mrow&gt;
            &lt;mi&gt;a&lt;/mi&gt;
            &lt;mo&gt;&amp;#x2062; &lt;!-- invisible times --&gt;&lt;/mo&gt;
            &lt;msup&gt;
              &lt;mi&gt;x&lt;/mi&gt;
              &lt;mn&gt;2&lt;/mn&gt;
            &lt;/msup&gt;
         &lt;/mrow&gt;
         &lt;mo&gt;+&lt;/mo&gt;
         &lt;mrow&gt;
            &lt;mi&gt;b&lt;/mi&gt;
            &lt;mo&gt;&amp;#x2062; &lt;!-- invisible times --&gt;&lt;/mo&gt;
            &lt;mi&gt;x&lt;/mi&gt;
         &lt;/mrow&gt;
         &lt;mo&gt;+&lt;/mo&gt;
         &lt;mi&gt;c&lt;/mi&gt;
      &lt;/mrow&gt;
      &lt;mo&gt;=&lt;/mo&gt;
      &lt;mn&gt;0&lt;/mn&gt;
    &lt;/mrow&gt;
  &lt;/math&gt;
&lt;/div&gt;</pre>
	<p>Similarly:</p>
	<p><code> 
&lt;i&gt;f&lt;/i&gt;(&lt;i&gt;x&lt;/i&gt;)
 = &lt;i&gt;x&lt;/i&gt;&lt;sup&gt;2&lt;/sup&gt; + &lt;i&gt;x&lt;/i&gt; - 2
</code></p>
	<p>Accessible example of the same function, using the math role, appropriate label, and MathML rendering: </p>
	<pre xml:space="preserve">&lt;div role="math"&gt;
  &lt;math xmlns='http://www.w3.org/1998/Math/MathML'&gt;
    &lt;mrow&gt;
      &lt;mrow&gt;
         &lt;mi&gt;f&lt;/mi&gt;
         &lt;mo&gt;&amp;#x2061;&lt;/mo&gt;
         &lt;mrow&gt;
            &lt;mo&gt;(&lt;/mo&gt;
            &lt;mrow&gt;
               &lt;mi&gt;x&lt;/mi&gt;
            &lt;/mrow&gt;
            &lt;mo&gt;)&lt;/mo&gt;
         &lt;/mrow&gt;
      &lt;/mrow&gt;
      &lt;mo&gt;=&lt;/mo&gt;
      &lt;mrow&gt;
         &lt;msup&gt;
           &lt;mi&gt;x&lt;/mi&gt;
           &lt;mn&gt;2&lt;/mn&gt;
         &lt;/msup&gt;
         &lt;mo&gt;+&lt;/mo&gt;
         &lt;mi&gt;x&lt;/mi&gt;
         &lt;mo&gt;&amp;#x2212;&lt;/mo&gt;
         &lt;mn&gt;2&lt;/mn&gt;
      &lt;/mrow&gt;
    &lt;/mrow&gt;
  &lt;/math&gt;
&lt;/div&gt;</pre>
</div>
<div class="section" id="dragdrop">
  <h2><span class="tocnum">8. </span>  Drag-and-Drop Support </h2>
  <p>Drag-and-drop operations are a common feature of Rich Internet 
Applications (RIAs). Drag-and-drop features have traditionally 
challenged people with functional disabilities. These problems arise 
from the difficulty of manipulating the mouse, finding targets capable 
of receiving the object being dragged, and actually moving the object to 
the drop target. Screen readers and alternate input systems assist the 
user to some degree by allowing the user to simulate a click, drag, and 
release operation. It is then up to the user to find a target that, 
hopefully, will receive the object(s) being dragged. Additionally, the 
user may not be aware if the desired drop operation is supported or what 
source objects can be selected for dragging. The end result can be a 
very unproductive and frustrating experience.
 </p>
  <p>WAI-ARIA introduces two new <a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#attrs_dragdrop">Drag and Drop properties</a> that aide Web application authors with the drag and drop process, called <em>aria-grabbed</em> and <em>aria-dropeffect.</em> The property <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-grabbed"><code>aria-grabbed</code> (state)</a> is applied to the source(s) being dragged, while <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-dropeffect"><code>aria-dropeffect</code></a> is applied to the target(s). Use of these  properties--combined with best practices for enabling the user to select the appropriate drag operations and for assigning appropriate keyboard operations for dragging and dropping--will vastly improve the accessibility of drag and drop functionality. The following steps will guide you through the process. </p>
  <ol><li>
      <p><strong>Identify draggable objects</strong></p>
      <p>Set the initial <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-grabbed"><code>aria-grabbed</code> (state)</a> state of all draggable interface objects. 
        Roles that typically support drag and drop operations are <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listitem"><code>listitem</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treeitem"><code>treeitem</code></a>. The default state for all  objects is assumed to be undefined, meaning that they are not draggable.  For objects that may be dragged, set the <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-grabbed"><code>aria-grabbed</code> (state)</a> state to "false".  This will allow assistive technologies to indicate which objects are draggable and potentially facilitate in choosing the objects to grab. </p>
        <p class="note">Objects that can be dragged need to have a determinable role. HTML tags such as <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code>  provide no semantics, unlike <code>&lt;select&gt;</code>, and would require you to set the WAI-ARIA role attribute.</p>
      
      <p>This  step clearly marks elements that can be "grabbed" for drag-and-drop operation. Assistive technologies, such as screen readers or alternate  input devices, can help the user move focus directly to the grab-supporting objects without having to navigate through all the  elements and to guess which could be ready to initiate a drag operation.  Although not necessary, authors or intermediaries could use CSS to  highlight those elements that may be grabbed. At this point, qualified drop targets cannot be determined as they are determined based on the objects being dragged--which have not yet been selected.</p>
      <p>All grabbable objects must be  navigable using the keyboard. </p>
    </li><li>
      <p><strong>Allow the user to initiate the appropriate drag operation using the keyboard</strong></p>
      <p>The author must provide a keyboard accessible way of selecting one or 
more elements to drag. It is recommended that the space bar be used for 
selection.  It is further recommended that <kbd>Shift+Space</kbd> be used to select 
multiple objects and define a contiguous set; and that control+space be 
used to define a noncontiguous set.  As each object is selected, its 
<a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-grabbed"><code>aria-grabbed</code> (state)</a> property must be set to "true", giving the ATs references as 
to what has been grabbed.  It is recommended that <kbd>Ctrl+M</kbd> be supported 
to indicate that all objects have been selected for drag.</p>
<p class="note">
Note: Selection of the objects to be dragged may differ depending on 
their type. For example, a list of emails might be selected one at a time or many at a time in contiguous or non-contiguous manner using the <kbd>Space</kbd> key as indicated above. However, text in 
a document might better be selected by positioning the cursor at the 
beginning of a word and holding down the <kbd>Ctrl</kbd> key while using the 
right and left arrow keys to mark the letters you wish to move.</p>
    </li><li>
      <p><strong>Mark the drop targets</strong></p>
      <p>When the user has completed selecting source objects to drag, you must indicate which targets may receive them by setting the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-dropeffect"><code>aria-dropeffect</code></a> properties on those targets. This will indicate to the assistive technology that all objects have been grabbed as well as what targets are capable of receiving the drop.</p>
	  <p>When using a mouse, users click, hold the mouse button, and drag the mouse when moving the selected objects, and, by implication, are no longer selecting them.  With respect to keyboard users, the previous section, Item 2, "Allow the user to initiate the appropriate drag operation using the keyboard", recommends using Control+M to indicate the end of the selection phase.</p>
	  <dl><dt>* copy:</dt><dd>A duplicate of the source object will be dropped onto the target.</dd><dt>* move:</dt><dd>The source object will be removed from its original location and 
    dropped onto the target.</dd><dt>* link:</dt><dd>A reference or short cut to the dragged object will be 
    created in the target object.</dd><dt>* execute:</dt><dd>A function supported by the drop target is executed, using 
    the drag source as an input.</dd><dt>* popup:</dt><dd>The author must provide a popup menu or dialog to allow the 
        user to choose one of the drag operations (copy, move, reference) and 
    any other drag functionality, such as drag cancel.</dd><dt>* none:</dt><dd>no drop operation is supported. This is the default for all 
    objects.      </dd></dl>
      <p>Example:</p>
      <pre xml:space="preserve">
&lt;div role="treeitem" aria-dropeffect="copy move popup"&gt;
</pre>

      <p>
        CSS may also be used to highlight the targets to show sighted users 
        which objects can receive a drop of the grabbed source(s). Any object 
        without an <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-dropeffect"><code>aria-dropeffect</code></a> property set will have an assumed 
        aria-dropeffect value of "none." Any object with an <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-dropeffect"><code>aria-dropeffect</code></a> value 
        of "none" is ignored by ATs in the drop operation.      </p>
    </li><li>
      <p><strong>Implement keyboard functionality to assist the user and AT with 
executing the drop.</strong></p>
<p>After all objects have been grabbed, the author should provide standard 
keyboard accessible navigation (such as through tabbing) to enable the 
user to navigate to the desired drop target. To achieve this, you may 
optionally support <kbd>Shift+F10</kbd> to invoke a single select list of possible 
drop targets from which the user may choose a single drop target that, 
when selected, would move focus to that drop target.
Otherwise, you must provide a keyboard accessible way (through tabbing 
and arrowing) to allow the user to navigate to the drop target. The 
user's point of regard should be clearly visible during this navigation.</p>
<p>
When the user arrives at the drop target the author should provide a 
keyboard accessible way to drop the selected object(s) onto the target. 
<kbd>Ctrl+M</kbd> should be used to provide the most intuitive type of drop, 
either copy, move, or a shortcut. In the case of only one 
drop operation available, the <kbd>Ctrl+M</kbd> should be used to drop the selected object(s) 
onto the target.</p>
<p>
If drop target supports additional drop operations, then the  
author should provide a WAI-ARIA-enabled pop-up menu from which the user 
can choose supported operations from the list. A recommended way to 
invoke this menu is to use the <kbd>Shift+Ctrl+M</kbd> key sequence when focus 
is on the drop target. Furthermore, the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-dropeffect"><code>aria-dropeffect</code></a> property should include "popup" in its list of values to indicate that a 
keyboard accessible menu is provided. After the user has selected an 
action from the pop-up menu, the menu must close, with focus returning 
to the drop target. If the user does not choose an action and instead 
presses the <kbd>Esc</kbd> key, the application must dismiss the menu, 
returning focus to the drop target.</p>
    </li><li><p><strong>Cancelling a drag operation</strong></p>
      <p>Users can cancel the entire drag operation at any time, with one exception, by pressing the <kbd>Esc</kbd> key.  The one exception is when the drop operations pop-up menu is displayed (see previous step four above).  In this case, <kbd>Esc</kbd> simply dismisses the pop-up, and a second <kbd>Esc</kbd> keystroke is needed to cancel the drag operation.  When the drag operation is so cancelled, all <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-dropeffect"><code>aria-dropeffect</code></a> properties are set to "none", all grabbable objects' <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-grabbed"><code>aria-grabbed</code> (state)</a> properties are set to "false", and keyboard focus returns to the  last grabbed source object. </p>
    </li><li>
      <p><strong>Clean-up after drag/drop</strong></p>
      <p>Once  the drop has occurred, you should clean up the DOM as you would do for drag-and-drop operation. This should include setting:</p>
		<ul><li>All  <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-dropeffect"><code>aria-dropeffect</code></a> properties to "none" or remove them altogether.</li><li>All <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-grabbed"><code>aria-grabbed</code></a> of draggable objects to "false".</li><li>All objects that are not grabbable must either omit the <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-grabbed"><code>aria-grabbed</code></a> property or have an <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-grabbed"><code>aria-grabbed</code></a> property set to "undefined."</li><li>Focus on the appropriate DOM element, and its role must also be determinable.</li></ul>
<p class="note">Other methods of performing the same 
operation as drag-and-drop may be the best way to meet the accessibility 
requirements. As an example, when moving a mail message from the inbox 
to another folder, a list of those folders could be presented in a 
select list as an alternative to drag-and-drop.</p>
    </li><li>
      <p><strong>Document non-recommended keyboard navigation</strong></p>
      <p>If the author must  use alternatives to the keyboard 
navigation  recommended  here, it should be documented on the page.</p>
</li></ol>
 
</div>
<div class="section" id="aria-write">
  <h2><span class="tocnum">9. </span> States and Properties Modified by an External Assistive Technology</h2>
  <p>States and Properties that an Assistive Technology is likely to change: </p>
  <ul><li>aria-activedescendant </li><li>aria-expanded</li><li>aria-grabbed</li><li>aria-selected </li><li>aria-sort</li><li>aria-valuenow</li></ul>
  <p>Authors should  monitor changes to these properties by monitoring &lt;a href="<a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-MutationEvent">http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-MutationEvent</a>"&gt;DOM  Mutation events&lt;/a&gt; for attribute changes and respond accordingly by  making the appropriate changes to your web application. Note that if any of these states and properties are set in error, the Web application is responsible for handling the error condition.</p>
  <p>The following States and Properties are unlikely to be manipulated by an assistive technology: An AT would need to have greater understanding of the application and the results could be adverse.</p>
  <ul><li>aria-atomic</li><li>aria-autocomplete</li><li>aria-busy</li><li>aria-checked</li><li>aria-controls</li><li>aria-describedby</li><li>aria-disabled</li><li>aria-dropeffect</li><li>aria-flowto </li><li>aria-haspopup</li><li>aria-hidden  </li><li>aria-invalid </li><li>aria-labelledby </li><li>aria-level</li><li>aria-live </li><li>aria-multiline</li><li>aria-multiselectable</li><li>aria-owns</li><li>aria-posinset</li><li>aria-pressed</li><li>aria-readonly</li><li>aria-relevant </li><li>aria-setsize</li><li>aria-valuemax</li><li>aria-valuemin</li><li>aria-valuetext</li></ul>
  
</div>
<div class="section" id="aria_ex">
  <h2><span class="tocnum">10. </span> Design Patterns</h2>
  <p>For these widgets and structures, this document  describes the keyboard interaction and identifies the relevant WAI-ARIA roles, states, and properties. </p>
<p>If the host language does not define key mappings, such as hot keys, and the author defines key mappings other than those described here or in <a href="#dragdrop">Drag-and-Drop Support</a>, then the author must provide documentation of those key mappings. These mappings can be provided in the contents of the web page, or in the case of a more complex application, within the help file documentation and training materials.</p>
<p class="note">Note: Although users of Mac OS X are familiar with using the Command key (<kbd>Cmd</kbd>) instead of the Control key (<kbd>Ctrl</kbd>), the Command 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 "Control" modifier key for WAI-ARIA widget interaction is specified as "Control" on all platforms, including Mac OS X.</p>
<ul class="miniindex"><li><a class="widget-reference" href="#accordion">accordion</a></li><li><a class="widget-reference" href="#alert">alert</a></li><li><a class="widget-reference" href="#autocomplete">autocomplete</a></li><li><a class="widget-reference" href="#button">button</a></li><li><a class="widget-reference" href="#checkbox">checkbox</a></li><li><a class="widget-reference" href="#combobox">combobox</a></li><li><a class="widget-reference" href="#datepicker">datepicker</a></li><li><a class="widget-reference" href="#dialog_modal">dialog_modal</a></li><li><a class="widget-reference" href="#dialog_nonmodal">dialog_nonmodal</a></li><li><a class="widget-reference" href="#dialog_tooltip">dialog_tooltip</a></li><li><a class="widget-reference" href="#draganddrop">draganddrop</a></li><li><a class="widget-reference" href="#grid">grid</a></li><li><a class="widget-reference" href="#landmarks">landmarks</a></li><li><a class="widget-reference" href="#link">link</a></li><li><a class="widget-reference" href="#listbox_div">listbox_div</a></li><li><a class="widget-reference" href="#mediaplayer">mediaplayer</a></li><li><a class="widget-reference" href="#menu">menu</a></li><li><a class="widget-reference" href="#menubutton">menubutton</a></li><li><a class="widget-reference" href="#popupmenu">popupmenu</a></li><li><a class="widget-reference" href="#popuphelp">popuphelp</a></li><li><a class="widget-reference" href="#radiobutton">radiobutton</a></li><li><a class="widget-reference" href="#richtext">richtext</a></li><li><a class="widget-reference" href="#slider">slider</a></li><li><a class="widget-reference" href="#slidertwothumb">slidertwothumb</a></li><li><a class="widget-reference" href="#spinbutton">spinbutton</a></li><li><a class="widget-reference" href="#tabpanel">tabpanel</a></li><li><a class="widget-reference" href="#toolbar">toolbar</a></li><li><a class="widget-reference" href="#tooltip">tooltip</a></li><li><a class="widget-reference" href="#treegrid">treegrid</a></li><li><a class="widget-reference" href="#TreeView">TreeView</a></li><li><a class="widget-reference" href="#windowsplitter">windowsplitter</a></li><li><a class="widget-reference" href="#wizard">wizard</a></li></ul>
  <div id="aria_ex_widget">
    <h4>Global Recommendations </h4>
    <p>The following may apply to some or all widgets. </p>
    <ul><li><kbd>Ctrl+Z</kbd> Optionally a developer may choose to implement   undo functionality as needed. It is recommended that Control + Z be used. </li><li><kbd>Ctrl+Y</kbd> Optionally a developer may choose to implement   redo functionality as needed. It is recommended that Control + Y be used. </li><li><kbd>Ctrl+C</kbd> Copies to clipboard </li><li><kbd>Ctrl+V</kbd> Pastes from clipboard </li><li><kbd>Ctrl+X</kbd> Copies to clipboard and cuts </li><li><kbd>Shift+F10</kbd> is used to bring up an associated <a href="#popupmenu">Popup Menu</a> </li><li><strong>Widgets within Widgets</strong> The general navigation model is for   a user to tab to a widget, interact with the controls in that widget and then   tab to move focus to the next widget in the tab order. By extension, when the   construct of a widget contains another widget, tab will move focus to the   contained widget because it is the next item in the tab order. This continues   down the layers of widgets until the last widget is reached. For example: We   have two widgets A and B on a page. Widget A contains within it Widget C and   Widget C contains within it Widget D. When tabbing, focus would land on Widget   A, then another tab would focus on C and then another tab would focus on widget   D. Because D is the last widget in C and C is the last widget in A one more   tab would move focus to B. </li></ul>
</div>
    <hr/>
    <div class="widget" id="accordion">
    <h3 class="widget-name"><code>Accordion</code> <span class="type-indicator">(widget)</span></h3>
      <table cellspacing="0" class="widget-features"><caption>
        Characteristics:
        </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"><p>An accordion component is a collection of expandable panels associated with a common outer container. Panels consist of a header and an associated content region or panel. The primary use of an Accordion is to present multiple sections of content on a single page without scrolling, where all of the sections are peers in the application or object hierarchy. The general look is similar to a tree where each root tree node is an expandable accordion header. The user navigates and makes the contents of each panel visible (or not) by interacting with the Accordion Header. Terms for understanding accordions include:</p>
<dl><dt>accordion component:</dt><dd>Collection of panels within a common outer pane.</dd><dt>accordion header:</dt><dd>Label area of an accordion panel. This is where you find the control to expand or collapse the panels.</dd><dt>accordion panel:</dt><dd>Contents area associated with an accordion header. 
</dd></dl>
            
            </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li><kbd>Tab</kbd> - When focus is on an accordion header, pressing the <kbd>Tab</kbd> key moves focus in the following manner:
<ol><li>If interactive glyphs or menus are present in the accordion header, focus   moves to each in order. </li><li>When the corresponding panel is expanded (its <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-expanded"><code>aria-expanded</code></a> state   is 'true'), then focus moves to the first focusable element in the panel. </li><li>If the  panel is collapsed (its aria-expanded state is 'false' or   missing), OR, when the last interactive element of a panel is   reached, the next <kbd>Tab</kbd> key press moves focus as follows:
                    <ul><li>If a subsequent accordion panel is already   expanded, focus moves to the first focusable element in this subsequent   panel. </li><li>If no subsequent accordion panel is expanded, focus moves to the first focusable element   outside the accordion component. </li></ul>
                  </li></ol>
              </li><li><kbd>Left arrow</kbd>
                <ul><li>When focus is on the accordion header, a press of up/left arrow keys moves focus to   the previous logical accordion header. </li><li>When focus reaches the first header, further up/left arrow key presses optionally   wrap to the first header. </li></ul>
              </li><li><kbd>Right arrow</kbd>
                <ul><li>When focus is on the accordion header, a press of down/right moves focus   to the next logical accordion header. </li><li>When focus reaches the last header, further down/right arrow key presses optionally   wrap to the first header </li></ul>
              </li><li><kbd>Up arrow</kbd> - behaves the same as left arrow </li><li><kbd>Down arrow</kbd> - behaves the same as right arrow </li><li><kbd>Ctrl+Up arrow</kbd> - Moves focus from anywhere in the accordion   content to its associated accordion header or tab respectively. </li><li><kbd>Ctrl+PageUp</kbd> -
                <ul><li>When focus is inside of an accordion pane, pressing <kbd>Ctrl-PageUp</kbd> moves focus   to the accordion header of the previous accordion pane. </li><li>When focus is in the first accordion header content, pressing <kbd>Ctrl-PageUp</kbd>  optionally moves focus to the last accordion header. </li><li>Focus will simply move to the header and will require Enter/space to   expand/collapse the accordion pane. </li></ul>
              </li><li><kbd>Ctrl+PageDown</kbd> -
                <ul><li>When focus is inside of an accordion pane, pressing <kbd>Ctrl-PageDown</kbd> moves   focus to the header of the accordion pane. </li><li>When focus is in the last accordion header content, pressing <kbd>Ctrl-PageDown</kbd> optionally moves focus to the first accordion header. </li><li>In the case of an accordion, focus simply moves to the header and requires <kbd>Enter</kbd>/<kbd>Space</kbd> to expand/collapse the accordion pane. </li></ul>
              </li><li><kbd>End</kbd> - When focus is on the accordion header, an <kbd>End</kbd> key press moves  focus to the last accordion header. </li><li><kbd>Home</kbd> - When focus is on the accordion header, a <kbd>Home</kbd> key press moves   focus to the first accordion header. </li><li><kbd>Enter/Space</kbd> - When focus is on an accordion header, pressing <kbd>Enter</kbd>/<kbd>Space</kbd> toggles the expansion of the corresponding panel.
                <ul><li>If collapsed, the panel is expanded, and its aria-expanded state is set to   'true'. </li><li>If expanded, the panel is collapsed and its aria-expanded state is set to   'false'. </li></ul>
              </li><li><kbd>Shift+Tab</kbd> - Generally the reverse of <kbd>Tab</kbd>.</li><li><kbd>Alt+Del</kbd> -
                
                <ul><li>When deletion is allowed, with focus anywhere within the tab panel or tab, pressing <kbd>Alt-Del</kbd> will delete the current tab and tab panel from the tabbed interface control. If additional tabs remain in the tabbed interface, focus goes to the next tab in the tab list. If no additional tabs remain, then focus moves to the last place that held focus in the previous tab panel.</li><li>An alternative to providing a keystroke to close a tab is to provide a context menu that is associated with the tab title. When focus is on the tab, pressing <kbd>Shift-F10</kbd> or pressing the right mouse button will open a context menu with the close choice.</li><li>A warning should be given to the user before allowing the delete to occur.</li></ul>
</li></ul>
            <p>In Firefox, pressing <kbd>Ctrl+PageUp</kbd> / <kbd>Ctrl+PageDown</kbd> moves between browser tabs. Firefox also supports <kbd>Ctrl+Tab</kbd> and <kbd>Ctrl+Shift+Tab</kbd> to move between tabs. Internet Explorer 7 also uses   <kbd>Ctrl+Tab</kbd> and <kbd>Ctrl+Shift+Tab</kbd>. There may be advantages to using   <kbd>Ctrl+PageUp</kbd>/<kbd>PageDown</kbd> as the keys to change tabs because it is a recognizable   keystroke to at least Firefox users and it is also supported by the Windows   operating system to move between panels in a tabbed dialog.</p>
            <p>You should be aware of two issues with using <kbd>Ctrl+PageUp</kbd>/<kbd>PageDown</kbd>: </p>
            <ul><li>The first arises when the user is within a tabbed interface control on a Web   page. Here they can not easily switch browser tabs without first moving focus   outside of the tabbed interface control. This may be acceptable. </li><li>The second   arises when the entire web page is a tabbed interface control. In this case the   user could not switch browser tabs unless the control on the web page ignored   the <kbd>Ctrl+PageUp</kbd>/<kbd>PageDown</kbd> keypress (and thus letting the browser access it) when   the first or last tab was reached. </li></ul>            </td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><ul><li>The accordion component must have a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tablist"><code>tablist</code></a> and have   <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-multiselectable"><code>aria-multiselectable</code></a>="true" This will enable an assistive technology, such as   screen reader, to convey that the tablist is an accordion or a multiselectable   tablist. This will also tell the user that the keyboard navigation matches an   accordion and not a tablist. </li><li>Contained within the tablist is a set of tab/tabpanel pairs. </li><li>Each header tab in the tablist has a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tab"><code>tab</code></a>. </li><li>The accordion panel uses the role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tabpanel"><code>tabpanel</code></a> and should have an   <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> relationship referencing the correponding header having a role   of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tab"><code>tab</code></a></li><li>The tabpanel is considered a grouping for all content consisting of that   tabpanel. </li><li>An accordion should manage the expanded/collapsed state of each tab by   maintain its <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-expanded"><code>aria-expanded</code></a> state. </li><li>An accordion should manage the selected state of each tab by maintaining its <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-selected"><code>aria-selected</code></a> state. </li><li>An accordion should convey the visibility of each tabpanel by maintaining   its <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-hidden"><code>aria-hidden</code></a> state. </li></ul>              </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><p><a href="http://test.cita.uiuc.edu/aria/tabpanel/tabpanel2.php">Tabpanel Accordion</a></p></td></tr></tbody></table>
    
</div>
    <hr/>
    <div class="widget" id="alert">
      <h3 class="widget-name"><code>Alert</code> <span class="type-indicator">(widget)</span></h3>
      <table cellspacing="0" class="widget-features"><caption>
        Characteristics:
        </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">A message with important information</td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p>An alert (WAI-ARIA live region) does not require any keyboard shortcuts</p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><p> The widget has a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alert"><code>alert</code></a>. It is a child of the role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#region"><code>region</code></a>. And it can have a child with role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alertdialog"><code>alertdialog</code></a>. </p></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><p><a href="http://test.cita.uiuc.edu/aria/alert/alert1.php">Alert</a></p></td></tr></tbody></table>
    </div>
    <hr/>
<div class="widget" id="autocomplete">
      <h3 class="widget-name"><code>Auto Complete</code> <span class="type-indicator">(widget)</span></h3>
      <table cellspacing="0" class="widget-features"><caption>
        Characteristics:
        </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"><p>A textbox and an associated   drop-down list of choices where the choices offered are filtered based on the information typed   into the box. Typically, an icon associated with the textbox   triggers the display of the drop-down list of choices. An editable auto-complete accepts text entry of choices that are not in the list. An example of an editable auto-complete is the URL field in the   browsers. </p></td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li>With focus in an empty textbox, press <kbd>Down Arrow</kbd>, <kbd>Up Arrow</kbd>,   <kbd>Alt+Down Arrow</kbd>, or <kbd>Alt+Up Arrow</kbd> to display the entire list of choices. Focus remains in the textbox and no choice is highlighted. </li><li>Press the <kbd>Down Arrow</kbd>  to highlight the first choice in the list. </li><li>Press the <kbd>Down Arrow</kbd> and <kbd>Up Arrow</kbd> keys to   highlight the desired choice in the list. </li><li>Note that the arrows will wrap through   the textbox when the top or bottom of the list is reached. For example, pressing   the down arrow when the last choice is highlighted will move focus back to the   textbox, pressing down again will move focus to the first item in the list.   Likewise, with focus in the textbox and the list displayed, pressing up arrow   will move focus to the last item in the list. </li><li>When a choice is highlighted using   the arrow keys, the highlighted choice is displayed in the textbox. </li><li>Press Enter   to select the highlighted choice and close the drop-down list.   This mimics the behavior of the HTML select element. </li><li>With focus in an empty textbox, type <strong>any letter</strong> key. If any of   the available choices begin with the letter typed, those choices are displayed   in a drop down. If the letter typed does not match any of the available choices   the drop-down list is not displayed. </li><li>With focus in textbox with an existing value type <strong>additional   letters.</strong> As the user types letters the list of choices is filtered so   that only those that begin with the typed letters are displayed. </li><li>Until the user   presses the arrow keys to highlight a particular choice, only the typed letters   are displayed in the textbox. </li><li>In an editable auto-complete, if no   choices match the letter(s) typed, the drop down list closes. </li><li>In a non-editable auto-complete, any letters that do not result in a match from   the list are ignored, the drop down list of choices remains static until the   user presses Escape to clear the text field, Backspace to remove some of the   letters previously typed, or types an additional letter that results in a valid   list of choices. </li><li>Navigation through the list of choices and display of the   highlighted choice in the textbox works as described above.<br clear="none"/>
                  <em>Optional:   When a choice is highlighted via arrow key navigation, the input cursor is left   at the end of the typed entry and the highlighted choice is displayed in the   textbox with the characters after the input cursor selected. Typing an   additional character will remove the auto-completed portion and append the newly   typed character to the end of the previously typed characters. The list will be   filtered based on the additional character(s) typed.</em> </li><li>With focus in a textbox, press <kbd>Esc</kbd>
                  <ul><li>If there is no text in the textbox, pressing Escape closes the drop-down if   it is displayed. </li><li>For an editable autocomplete that has text in the textbox that was both   typed by the user and auto-completed by highlighting a choice using the   keyboard, the auto-completed portion of the text is cleared and the user typed   characters remain in the textbox. The drop-down list is closed. To completely   clear the textbox contents the user must use the backspace key to remove the   typed characters. This is how the Google search box in the Firefox UI works. <em>Recommend that  pressing the Escape key again   completely clears the textbox rather than relying on only the backspace   key.</em> </li><li>For a non-editable auto-complete that has text in the textbox that was both   typed by the user and auto-completed by highlighting a choice using the   keyboard, pressing escape closes the drop-down list and leaves the current   choice in the textbox. </li><li>For an editable or non-editable auto complete with text in the textbox that   was typed by the user and the mouse is highlighting a choice in the drop down   (keyboard navigation was NOT used), pressing escape closes the drop down and   leaves the typed text displayed in the text box. Need to consider if pressing   escape again should clear the typed text. The user must press the down arrow or   alt+down arrow or click the associated icon to invoke the drop-down list of   choices again. </li></ul>
                </li><li>Moving focus out of an empty auto complete field where a value is required   should either invoke an error or if a default value was initially assigned,   reset the value to the default value. </li><li>Moving focus out of an auto complete field that does not contain a valid   entry should either invoke an error or if a default value was initially   assigned, reset the value to the default value. </li></ul>
              <p class="note">It is good practice to limit the number of matching   items in the drop down to a reasonable number. The reasonable number is   determined by the task at hand. A list of the 50 US States is probably   reasonable, but a list containing all of the office numbers in a building is   probably not appropriate. </p>
         </td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><p> The widget has a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#combobox"><code>combobox</code></a>, and its parent role is <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#input"><code>input</code></a>. It has a child with role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#textbox"><code>textbox</code></a>. The property <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-autocomplete"><code>aria-autocomplete</code></a> indicates whether user input completion suggestions are provided. </p></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><a href="http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/_autoComplete.html" title="http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/_autoComplete.html" rel="nofollow">Dojo autocomplete</a></td></tr></tbody></table>
    </div>
<hr/>
<div class="widget" id="button">
  <h3 class="widget-name"><code>Button</code> <span class="type-indicator">(widget)</span></h3>
      <table cellspacing="0" class="widget-features"><caption>
        Characteristics:
        </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#button"><code>button</code></a> widgets allow for user-triggered actions, and they are most often used for discrete, atomic actions. Buttons support the optional state pressed. Buttons with this state present are toggle buttons. When  pressed is "true" the button is depressed, when pressed is "false" it  is not depressed.</td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p>With focus on the button, pressing <kbd>Space</kbd> or Enter keys executes the action for that button.</p>
              <ul><li>If the button activation closes the containing entity or launches another entity, then focus moves to the newly opened entity. </li><li>If  the button activation does not close or dismiss the containing entity,  then focus remains on the button. An example might be an Apply or  Recalculate button. </li></ul></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><ul><li> The button receives a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#button"><code>button</code></a>. </li><li>The button description receives the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> property. </li><li> When the action associated with a button is unavailable, the button displays in a <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-disabled"><code>aria-disabled</code></a> state. </li></ul></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><p><a href="http://www.mozilla.org/access/dhtml/button">XHTML button</a></p></td></tr></tbody></table>
      <hr/>
    </div>
    <div class="widget" id="checkbox">
      <h3 class="widget-name"><code>Check Box</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">A widget that has three possible values: true, false, or mixed.
          <p>Many checkboxes do not use the "mixed" value, and thus are effectively   boolean checkboxes. However, the aria-checked state supports the mixed value to   support cases such as installers where an option has been partially installed. </p></td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p>Two-State Check Box
              </p>
            <ul><li><kbd>Space</kbd> key toggles the selection, checking or unchecking   the box. </li></ul>
            <p>Three-State Check Box
            </p>
            <ul><li>If not checked, <kbd>Space</kbd> checks the check box. </li><li>If checked, <kbd>Space</kbd> unchecks the check box.</li><li>If partially checked, <kbd>Space</kbd> unchecks the check box. </li></ul></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><ul><li>The checkbox should have a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#checkbox"><code>checkbox</code></a>. </li><li>If  checked it should have the state <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-checked"><code>aria-checked</code></a>="true". </li><li>If not checked it should have the state <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-checked"><code>aria-checked</code></a>="false". </li><li>If partially checked, it should have the state <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-checked"><code>aria-checked</code></a>="mixed".</li><li>If you use an image to render the state of a checkbox, it should not appear   in the accessibility API mapping. This can be accomplished using CSS to render   it or setting a role of presentation on the image. </li><li>Put the checkbox in the tab order, such as by setting its <code>tabindex="0"</code>. </li><li>Checkboxes having a logical grouping should be children of a DOM element   whose role is <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#group"><code>group</code></a>. </li><li>The group should assign a label that is visible and referenced through the   <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> property set to the ID of the label. </li><li>Use an <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-describedby"><code>aria-describedby</code></a> property to add additional help information   to the checkbox or grouping. </li></ul></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Examples: </td><td class="widget-example" rowspan="1" colspan="1"><ul><li><a href="http://codetalks.org/source/widgets/checkbox/checkbox-tristate.html" target="_blank">Tri-State Checkbox</a></li><li><a href="http://codetalks.org/source/widgets/checkbox/checkbox.html">Two-State   checkbox</a></li><li><a href="http://codetalks.org/source/widgets/checkbox/checkbox1.html">Two-State   checkbox using CSS for image styling to remove images from accessibility tree as   would be expected on the desktop. This example illustrates how a group role is   used to group the checkboxes.</a></li><li><a href="http://codetalks.org/source/widgets/checkbox/checkbox2.html">Two-State   checkbox using role="presentation" on images to remove images them from the   accessibility tree as would be expected on the desktop. This example illustrates   how a group role is used.</a></li></ul></td></tr></tbody></table>

    </div>
    <hr/>
    <div class="widget" id="combobox">
      <h3 class="widget-name"><code>Combo Box</code> <span class="type-indicator">(widget)</span></h3>
        <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">A combo box enables the user to type in a field and at the same time chose a   predefined value from a list. By using the keyboard the user can select an item   from the list. After selection she will be able to type further characters in   the field.</td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li><kbd>Enter</kbd> selects an entry in the list if it was opened  </li><li><kbd>Left Arrow</kbd> or <kbd>Right Arrow</kbd> move the caret </li><li><kbd>Up Arrow</kbd> and <kbd>Down Arrow</kbd> moves focus up and down the list. As focus moves inside the dropdown list, the edit field is updated.</li><li><kbd>Page Up</kbd>/<kbd>Page Down</kbd> selects the next/previous pages item depending   on the lists size </li><li><kbd>Alt+Up Arrow</kbd> opens and closes the list. </li><li><kbd>Alt+Down Arrow</kbd> opens and closes the list. </li><li><kbd>Esc</kbd> closes the dropdown list, returns focus to the edit field, and does not change the current selection.</li><li><kbd>Typing a letter (printable character) key</kbd> moves focus to the next instance of a visible node whose title begins with that printable letter.</li></ul></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1">A combo box is a combination of text field, which may be editable, a drop button   to choose an item to place in the combo box, and a displayable list of items all   wrapped in the form of a single widget. Like text fields a combobox should be   labeled to determine the essence of the widget. Keyboard focus within the widget   must be managed by the widget. Comboboxes are used extensively in graphical user   interfaces and the design pattern for the widget should be semantically correct.
            <ul><li>The container element should that wraps the combobox must have a role of   "combobox." </li><li>The first element within the combobox should be an input text field and is   responsible for managing the keyboard focus between the textfield and the list   as well as displaying the list. The textfield should be in the tab order. If   you create a textfield without using a standard HTML textfield form control then   you must ensure that it is in the tab order. </li><li>If the textfield is not editable it must have have aria-readonly="true." </li><li>The next element should be an html &lt;button&gt; or another html element   with a role of "button". This button should be in the tab order and be   responsible for opening the list. </li><li>The next element constitute with a role="list" representing the drop down   list and it should managed the keyboard navigation between each list item and   back to the textfield if necessary. </li><li>Each item in the list should have a role="listitem". Listitems should not be   in the tab order. </li><li>You should provide a label which labels the combobox by referencing the   textfield in the combobox. You can use an aria-label to associate this label   with the combobox or you may use the HTML &lt;label&gt; element and its for   attribute to reference the textfield. </li></ul></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><ul><li><a href="http://codetalks.org/source/widgets/combobox/combo-editable.html" target="_blank">Editable HTML ComboBox</a></li><li><a href="http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/_autoComplete.html?testWidget=dijit.form.ComboBox">Dojo   nightly build combobox</a></li><li><a href="http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/_autoComplete.html?testWidget=dijit.form.FilteringSelect">Dojo   nightly build combobox with autocomplete</a></li></ul>     </td></tr></tbody></table>
</div>
<hr/>
    <div class="widget" id="datepicker">
        <h3 class="widget-name"><code>Date Picker</code> <span class="type-indicator">(widget)</span></h3>
        <table cellspacing="0" class="widget-features"><caption>
          Characteristics:
          </caption><tbody><tr><td class="widget-description-head" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">The DatePicker
      widget allows the user to select a date, multiple dates or date ranges.
        The DatePicker should at least show one month. All navigation that is described
        below depends on the application. If no range selection is possible this interaction
        can be ignored. Also navigation to the past might be optional. Each week might be
        labeled with the corresponding calendar week number.
      <p>
      As a general rule the actual calendar portion of the date picker should follow a table
      structure where days of the week and calendar day numbers are layed out in table cells. This
      provides context so an assistive technology can render the day of the week; its corresponding
      numeric calendar day, and week number if necessary. Consequently, it is best to start
      with an HTML table and apply WAI-ARIA semantics for a grid. However, should the author
      wish to uses a div or span to represent the cells then the DOM structure for a table should be
      duplicated with rows marked with role="row."
      </p>  
    </td></tr><tr><td class="widget-keyboard-head" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1">
        <p>
            Keyboard navigation on days that are not included the currently displayed month
            should move to the month automatically and lead to the day in the next or previous
            month.
        </p>
        <ul><li><kbd>Tab</kbd> - Like other widgets, the date picker widget receives focus by tabbing into it. Once focus is received, focus is repositioned on today's date in a grid of days and weeks. A second tab will take the user out of the date picker widget. Focus initially is placed on today's date.</li><li><kbd>Shift+Tab</kbd> - reverses the direction of the tab order. Once in the widget, a Shift+Tab will take the user to the previous focusable element in the tab order.</li><li><kbd>Up Arrow</kbd> and <kbd>Down Arrow</kbd> - goes to the same day of the week in the previous or next week respectively. If the user advances past the end of the month they continue into the next or previous month as appropriate.</li><li><kbd>Left Arrow</kbd> and <kbd>Right Arrow</kbd> - advances one day to the next, also in a continuum. Visually focus is moved from day to day and wraps from row to row in a grid of days and weeks.</li><li><kbd>Control+Page Up</kbd> - Moves to the same date in the previous year.</li><li><kbd>Control+Page Down</kbd> - Moves to the same date in the next year.</li><li><kbd>Space</kbd> -
      
                <ul><li>Singleton Mode: acts as a toggle either selecting or deselecting the date.</li><li>Contiguous Mode: Similar to selecting a range of text. <kbd>Space</kbd> selects the first date. <kbd>Shift+Arrow</kbd>s add to the selection. Pressing <kbd>Space</kbd> again deselects the previous selections and selects the current focused date.</li><li>Non-Contiguous Mode: <kbd>Space</kbd> may be used to select multiple non-contiguous dates.</li></ul>
            </li><li><kbd>Home</kbd> - Moves to the first day of the current month.</li><li><kbd>End</kbd> - Moves to the last day of the current month.</li><li><kbd>Page Up</kbd> - Moves to the same date in the previous month.</li><li><kbd>Page Down</kbd> - Moves to the same date in the next month.</li><li><kbd>Enter</kbd> - Submits the form.</li><li><kbd>Esc</kbd> - in the case of a popup date picker, closes the widget without any action.</li></ul>
        <p class="note">Navigation into the past is optional</p>
        <p class="note">
        Do not implement keyboard navigation schemes that would place more than one calendar
        day in the tab order at any time as this impacts the usability of keyboard navigation.
        For example, using HTML anchors for the gridcells places them all in the tab order impacting
        the usability of keyboard navigation.</p>        
</td></tr><tr><td class="widget-keyboard-head" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-keyboard" rowspan="1" colspan="1">
        <ul><li>The current month should have a label representing the month and year. This
           should have a role header but is not essential. This "label" should have a unique ID.</li><li>If the author would like to ensure that a label is announced by a screen reader, as the label changes, the label should
           include live region properties: aria-live="assertive" and aria-atomic="true"</li><li>The container for the day of week headers and numeric days of the week should have a role of grid</li><li>The grid should have an aria-labelledby property with a value equivalent to the id of the label for the grid</li><li>Each name for the day of the week should have a role columnheader and
           they should not be navigable via the keyboard.</li><li>Each numeric day of the week should have the role gridcell.</li><li>When a day is selected it should have aria-selected="true" otherwise it should be set to "false" or removed.</li><li>Changes in aria states, identified here, as well as focus, should be clearly styled to show the user where their point of regard is and what days are selected.</li></ul> 
        When the datepicker is active a calender day of the week should always have focus. This can be achieved
        by setting the tabindex on that day as appropriate and then using script to give it focus. Alternatively,
        the grid container could set aria-activedescendant to the id of the currently focused gridcell. Keep
        in mind that older browsers may not support aria-activedescendant.    </td></tr><tr><td class="widget-keyboard-head" rowspan="1" colspan="1">Example: </td><td class="widget-keyboard" rowspan="1" colspan="1">
      <a href="http://codetalks.org/source/widgets/datepicker/datepicker.sample.html" target="_blank">HTML DatePicker</a></td></tr></tbody></table>

  </div>
      <hr/>
    <div class="widget" id="dialog_modal">
      <h3 class="widget-name"><code> Dialog (Modal) </code> <span class="type-indicator">(widget)</span></h3>
        <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"><p>A dialog is a small application window that sits above the application and is   designed to interrupt the current processing of an application in order to   prompt the user to enter information or require a response (<a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#dialog"><code>dialog</code></a>). A modal dialog is a dialog that takes and holds focus until the dialog is   closed or submitted. </p></td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p>Keyboard navigation within a modal dialog includes these aspects:</p>
            <ul><li><kbd>Enter</kbd> If the purpose of the dialog is to gather   information, the dialog should have a mechanism to submit the data gathered   usually via a keyboard accessible button. The Enter key should serve as the   default submit action. </li><li><kbd>Esc</kbd> There should be a method to close the dialog without   taking any action. This could be implemented via a cancel button which is   keyboard accessible. It is recommended that a dialog also be cancelled by   pressing the escape key with focus on any item. </li><li><kbd>Tab</kbd> Focus must be held within the dialog until it is   cancelled or submitted. As the user presses tab to move within items in the   dialog, pressing tab with focus on the last focusable item in the dialog will   move focus back to the first focusable item in the dialog. </li><li><kbd>Shift+Tab</kbd> Likewise, if the user is shift-tabbing through   elements in the dialog, pressing shift-tab with focus on the first focusable   item in the dialog will move focus to the last item in the dialog. </li></ul>
              <p><strong>Notes:</strong> </p>
              <ul><li>If the current focus item has escape key behavior,   the press of the escape will be handled by the current item and the user may   have to press escape an additional time to close the dialog. </li><li>Even if the user clicks outside of the dialog on the   application which invoked the dialog, focus remains in the dialog. </li><li>Because the dialog is modal and the user can not   interact with the invoking application while the dialog is displayed, there is   not a requirement to make the dialog moveable via the mouse although this   behavior is recommended. </li><li>When the dialog is closed or cancelled focus should   return to the element in the application which had focus before the dialog is   invoked. This is usually the control which opened the dialog. </li><li>When a modal dialog opens focus goes to the first   focusable item in the dialog. Determining the first focusable item must take   into account elements which receive focus by default (form fields and links) as   well as items which may have a tabindex attribute with a positive value. If   there is no focusable item in the dialog, focus is placed on the dialog   container element. </li></ul>
</td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><p>A dialog has a role of aria-dialog, with a parent of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#window"><code>window</code></a> and child of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alertdialog"><code>alertdialog</code></a>. In addition to some global states and properties, it can have the state <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-expanded"><code>aria-expanded</code> (state)</a>.</p>
          <p>The dialog box title is provided by  <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-label"><code>aria-label</code></a> or <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> property.</p></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><ul><li><a href="http://download.dojotoolkit.org/release-1.2.3/dojo-release-1.2.3/dijit/tests/test_Dialog.html" title="http://download.dojotoolkit.org/release-1.2.3/dojo-release-1.2.3/dijit/tests/test_Dialog.html" rel="nofollow">Dojo 1.2.3 Release</a></li><li><a href="http://developer.yahoo.com/yui/examples/container/container-ariaplugin_clean.html" title="http://developer.yahoo.com/yui/examples/container/container-ariaplugin_clean.html" rel="nofollow">YUI dialogs -- use first two dialog buttons</a></li></ul>          </td></tr></tbody></table>
</div>
    <hr/>
    <div class="widget" id="dialog_nonmodal">
      <h3 class="widget-name"><code> Dialog (Non-Modal) </code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"><p>A dialog is a small application window that sits above the application and is   designed to interrupt the current processing of an application in order to   prompt the user to enter information or require a response (<a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#dialog"><code>dialog</code></a>). </p>
          <p>A non-modal dialog is one which is displayed and focusable at the same time   as the application which invoked it. Also like the modal dialog, focus via the   tab and shift-tab key must be maintained within the dialog. However, a non-modal   dialog should have a keyboard mechanism to return focus to the application while   leaving the dialog open. </p></td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li><kbd>Esc</kbd> cancels the dialog without taking any action </li><li><kbd>Enter</kbd> submits any data gathered in the dialog. </li><li><kbd>F6</kbd> is the recommended key to move focus between   the application and an open non-model dialog. </li></ul>
            <p><strong>Notes:</strong></p>
            <ul><li>The mouse user may click on either the application or   the dialog to change focus between the two. </li><li>In a Web application the non-modal dialog is usually   always displayed above the application page, rather than in a separate browser   window but that is not a requirement. </li><li>This dialog box is dragable by the mouse user and an   equivalent behavior (<a href="#draganddrop">Drag &amp; Drop</a>) should be   offered to the keyboard only user. </li></ul> </td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1">See Dialog (Modal).</td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"> </td></tr></tbody></table>
    </div>
    <hr/>
    <div class="widget" id="dialog_tooltip">
      <h3 class="widget-name"><code> Dialog (Tooltip) </code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p> </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"> </td></tr></tbody></table>
    </div>
    <hr/>
    <div class="widget" id="draganddrop">
      <h3 class="widget-name"><code> Drag &amp; Drop </code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p> </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><ul><li><a href="http://codetalks.org/source/widgets/draganddrop/draganddrop1.html" title="http://codetalks.org/source/widgets/draganddrop/draganddrop1.html" rel="nofollow">Tic tac toe</a></li><li><a href="http://codetalks.org/source/widgets/draganddrop/draganddrop2.html" title="http://codetalks.org/source/widgets/draganddrop/draganddrop2.html" rel="nofollow">Slide show</a></li></ul></td></tr></tbody></table>
    </div>
    <hr/>
<div class="widget" id="grid">
      <h3 class="widget-name"><code>Grid (Simple Data Tables)</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"><p>Unlike an HTML table, which is display only, a grid presents tabular data in   rows and columns that are navigable via the keyboard, and allows for cells to   be selected in the grid. The user moves focus through each data cell having a   role of gridcell, through the use of arrow keys. Each column has an associated   element with the role columnheader. Data cells carry the role gridcell. A grid   may also contain hierarchical rows. In this case the role of the grid container   should be treegrid rather than grid. This design pattern, and corresponding examples, reflect a basic two-dimensional grid without grids embedded within a gridcell. </p>
            <p>WAI-ARIA grids are not meant to replace the full functionality of a table. Consequently, there may be instances when you need to have cells span multiple columns or rows for which WAI-ARIA does not provide semantics. This can be achieved by overlaying grid and gridcell semantics onto  an HTML table to provide appropriate column and row span semantics. Authors should ensure that headers are properly marked using a native header tag or WAI-ARIA columnheader or rowheader semantics. The connection between gridcell and header can be achieved using standard HTML attribute header. In HTML, multiple column or row headers for one data cell can be identified through the use of a space separated list of header ids in the headers attribute. </p>
            <p>If a WAI-ARIA grid is not overlayed on a table, authors should mark the rowheader, columnheader, and gridcell roles on the appropriate elements. For gridcells that span multiple columns or have multiple headers, the author should apply the aria-labelledby property to the cell to the space delimited list of corresponding row or column header element IDs. Gridcells that span multiple rows or columns should be reflected in the keyboard navigation.</p>
<p>If a grid contains editable data, it should have both an editable mode and a navigation  mode.</p></td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p>There are two modes of keyboard interaction: </p>
            <ul><li>Navigation Mode (Read-Only) is the default mode, and allows quick   and intuitive navigation around the grid.
                <ul><li>The first <kbd>Tab</kbd> into the grid moves focus to the   first cell of the first row. </li><li>The second <kbd>Tab</kbd> leaves the grid and moves focus to the next   tabbable item on the page. </li><li>Subsequent <kbd>Tab</kbd>: Once focus has been moved inside the grid,   subsequent tab presses that re-enter the grid shall return focus to the cell that last   held focus. </li><li>Right/Left arrow keys navigate through the columns. There is no   wrap at the end or beginning of columns. </li><li>Up/Down arrow keys navigate through the rows. There is no wrap   at the first or last rows. </li><li><kbd>Home</kbd> moves the focus to the first cell of the current row. </li><li><kbd>End</kbd> moves the focus to the last cell in the current row. </li><li><kbd>Page Up</kbd> moves the focus to the first cell in the current   column </li><li><kbd>Page Down</kbd> moves the focus to the last cell in the current   column </li><li>Selecting Cells
                    <ul><li><kbd>Ctrl+Space</kbd> selects the current column. </li><li><kbd>Shift+Space</kbd> selects the current row. </li><li><kbd>Ctrl+A</kbd> selects the entire grid. </li><li><kbd>Shift+Arrow</kbd> selects contiguous cells. </li><li><kbd>Shift+F8</kbd> Allows additional cells to be added to a   previous selection to accomplish non-contiguous selection. </li></ul>
                      <p class="note">See <a href="#aria_ex_widget">Global Recommendations</a> for   information on copy and paste. </p>
                  </li></ul>
              </li><li>Actionable Mode (Interactive) allows the interaction with other   objects that might be found in the grid cells such as edit fields, links,   etc.
                <ul><li><kbd>F2</kbd> pressed anywhere inside the grid will enter Actionable   Mode. Focus will not be moved. </li><li><kbd>Enter</kbd> pressed while focus is on an actionable item will   enter Actionable Mode. Focus will remain on the actionable item that has focus. </li><li>Optionally, alphanumeric keys pressed while focus is on an   actionable item will enter Actionable Mode. Focus will remain on the actionable   item that has focus. </li><li>Using grid as an example, by default, pressing <kbd>Esc</kbd> anywhere inside the grid will mean exiting Actionable mode (by which the user may enter text or perform an action to complete a operation) and a return to Navigation Mode (where the user is allowed to move focus among elements). If a widget is in the current grid cell that also uses the <kbd>Esc</kbd> key, then it should cancel the event propagation. A subsequent press of the <kbd>Esc</kbd> key will return focus to the parent widget.</li><li><kbd>Tab</kbd> will move to the next actionable (tabbable) item in the   grid and stay within the grid wrapping at the bottom. In this mode each tabbable   object in each cell of the grid can be reached with the tab key. If multiple   tabbable items are located inside a single grid cell, the tab will stop at each   one. When the last tabbable item in a cell is reached the next tab will move to   the next tabbable item in the grid, wrapping at the last tabbable item in the   grid. </li><li><kbd>Shift+Tab</kbd> moves to the previous actionable (tabbable) item   in the grid and stays within the grid, wrapping at the top. </li></ul>
              </li></ul>
          <p class="note">It is recommended the developer use different styling   for the selection when the grid is not focused (hint: non-active selection is   often shown with a lighter background color). </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><ul><li>The DOM representation of the grid should follow the HTML DOM structure,   although it will be possible to use <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> to add a row or table cell. This   is an edge case and may not be supported by assistive technologies. </li><li>The grid container should have a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#grid"><code>grid</code></a>. </li><li>The data cells should have a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#gridcell"><code>gridcell</code></a>.</li><li>Each row should be clearly marked using a <code>&lt;TR&gt;</code> from HTML or by using a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#row"><code>row</code></a>.</li><li>Column and row headers may be represented by a <code>&lt;TH&gt;</code> if you are using an HTML   table or you may explicitly use an aria role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#columnheader"><code>columnheader</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#rowheader"><code>rowheader</code></a> respectively.</li><li>Whenever a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#gridcell"><code>gridcell</code></a> is selected, set <code>aria-selected="true"</code>. </li><li>Whenever a row is selected, set its role to <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#row"><code>row</code></a> and its   <code>aria-selected="true"</code> allowing an AT to quickly determine that the entire row is selected. </li><li>By default a grid is considered to be editable, meaning all gridcells are editable. Should you want to make a grid read-only, set     <code>aria-readonly="true"</code> on the document element having a <code>role="grid"</code>. This     will make all grid cells read-only.     To override the read-only status on an individual grid cell, set its <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-readonly"><code>aria-readonly</code></a> property to false. </li></ul></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1">
            <ul><li><a href="http://codetalks.org/source/widgets/grid/grid.sample.html">Simple   Grid</a></li><li><a href="http://codetalks.org/source/widgets/datepicker/datepicker.sample.html" target="_blank">HTML Grid as part of a date picker</a></li><li><a href="http://codetalks.org/source/widgets/grid/grid.html">HTML grid   overlaying a table in an application with a menu</a></li></ul>
        </td></tr></tbody></table>

  </div>
<hr/>
    <div class="widget" id="landmarks">
      <h3 class="widget-name"><code> Landmark Navigation </code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p> </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><ul><li> <a href="http://test.cita.uiuc.edu/aria/nav/nav1.php" title="http://test.cita.uiuc.edu/aria/nav/nav1.php" rel="nofollow">Illinois Navigation Example</a></li><li><a href="http://juicystudio.com/article/examining-wai-aria-document-andmark-roles.php" title="http://juicystudio.com/article/examining-wai-aria-document-andmark-roles.php" rel="nofollow">Juicy Studio</a> -- real world example </li><li> <a href="http://wiki.codetalks.org/wiki/index.php/Main_Page" rel="nofollow">Codetalks.org</a> -- another real world example </li></ul>            <p> </p></td></tr></tbody></table>
    </div>
    <hr/>
    <div class="widget" id="link">
      <h3 class="widget-name"><code>Link</code> <span class="type-indicator">(widget)</span></h3>
      <table cellspacing="0" class="widget-features"><caption>
        Characteristics:
        </caption><tbody><tr><td class="widget-description-head" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">The <code>Link</code> widget provides an interactive reference to a resource either locally in the application or to an external resource. </td></tr><tr><td class="widget-keyboard-head" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p>The Link is in the tab chain defined with the tabindex attribute. </p>
              <ul><li><kbd>Tab</kbd> moves focus to the Link. A second tab moves focus to   the next focusable item. </li><li><kbd>Space</kbd> or <kbd>Enter</kbd> executes the link. </li><li><kbd>Shift+F10</kbd> is used to bring up an associated Popup Menu. </li></ul></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1">Set a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#link"><code>link</code></a> on the element containing the text of the link.</td></tr><tr><td class="widget-keyboard-head" rowspan="1" colspan="1">Example: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li><a href="http://codetalks.org/source/widgets/link/link.html" target="_blank">HTML Link 1</a> </li><li><a href="http://codetalks.org/source/widgets/link/link.sample.html" target="_blank">HTML Link 2</a> </li></ul>
            </td></tr></tbody></table>
      <p> </p>
  </div>
    <hr/>
    <div class="widget" id="listbox_div">
    <h3 class="widget-name" id="listbox"><code>Listbox</code> <span class="type-indicator">(widget)</span></h3>
      <table cellspacing="0" class="widget-features"><caption>
        Characteristics:
        </caption><tbody><tr><td class="widget-description-head" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">A widget that allows the user to select one or more items from a   list of choices. (<a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listbox"><code>listbox</code></a>). </td></tr><tr><td class="widget-keyboard-head" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li><kbd>Tab</kbd>: When a list is tabbed to, select the first item if   nothing else is already selected. A second tab will take the user out of the   widget to the next tab stop on the page. </li><li>Up/down arrows navigate up and down the list. </li><li><kbd>Shift+Up Arrow</kbd> and <kbd>Shift+Down Arrow</kbd> move and extend the selection. </li><li>Typing letter or several letters to navigate (same letter   goes to each item starting with that, different letters go to first item   starting with that entire string). </li><li><kbd>Shift+F10</kbd>: If the current item has an associated context   menu, then this key combination will launch that menu. </li><li><strong>Selection</strong>
                  <ul><li>Checkbox - <kbd>Space</kbd> toggles <a href="#checkbox">checkboxes</a>, if the list items are checkable </li><li>Selectable List Items
                      <ul><li><kbd>Space</kbd> acts as a toggle to select and deselect the current   item. If previous items have been selected, it also deselects them and selects   the current item. </li><li><kbd>Shift+Space</kbd> selects contiguous items from the last   selected item to the current item. </li><li><kbd>Ctrl+Arrow</kbd> moves without selecting. </li><li><kbd>Ctrl+Space</kbd> selects non-contiguous items and adds the   current selected item to all previously selected items. </li><li><kbd>Ctrl+A</kbd> - It is recommended a checkbox, link or other   method be used to select all. The <kbd>Ctrl+A</kbd> key could be used to provide the   shortcut key.</li></ul>
                    </li></ul>
                </li></ul>
              <p class="note">It is recommended the developer use different styling for   the selection when the list is not focused (hint: non-active selection is often   shown with a lighter background color). </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><ul><li>The listbox container  has a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listbox"><code>listbox</code></a>.</li><li>Each entry in the listbox should have a role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#option"><code>option</code></a> and should be DOM  children of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#listbox"><code>listbox</code></a>.</li><li>If is not a DOM child of listbox, then it should be referenced in the listbox by   <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a>.</li><li>If all items in the listbox are not DOM children of the listbox, then  set their <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-setsize"><code>aria-setsize</code></a> and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-posinset"><code>aria-posinset</code></a> accordingly; otherwise, this information cannot  be computed for context by the user agent.</li><li>If the listbox is not part of another widget, then it should have a visible <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-label"><code>aria-label</code></a> referenced on the listbox by <br clear="none"/>
<a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a>.</li><li>Each selected list item should have <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-selected"><code>aria-selected</code></a>="true".</li></ul></td></tr><tr><td class="widget-keyboard-head" rowspan="1" colspan="1">Example: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li><a title="http://codetalks.org/source/widgets/listbox/listbox.html" href="http://codetalks.org/source/widgets/listbox/listbox.html" rel="nofollow">Single select listbox</a></li><li><a title="http://codetalks.org/source/widgets/listbox/listbox-owner.html" href="http://codetalks.org/source/widgets/listbox/listbox-owner.html" rel="nofollow">Listbox in an iframe</a></li></ul></td></tr></tbody></table>
    </div>
    <hr/>
<div class="widget" id="mediaplayer"><h3 class="widget-name"><code>Media Player</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p> </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"> </td></tr></tbody></table>
</div>
  <hr/>
<div class="widget" id="menu"><h3 class="widget-name"><code>Menu</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">A menu type of widget that offers the user a list of choices. It is often a list of links to important sections of a document or a   site. The menu role is appropriate when the list of links is presented in a   manner similar to a menu on a desktop application. A menubar is also considered   a form of menu. A menu should manage the focus of its descendants. </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li>If a menu bar item has focus and the menu is not open, then:
              <ul><li><kbd>Enter</kbd>, <kbd>Space</kbd>, or the up or down arrow keys opens the   menu and places focus on the first menu item in the opened menu or child menu   bar. </li><li>Left or right arrow keys move focus to the adjacent menu   bar item. </li></ul>
            </li><li>When a menu is open and focus is on a menu item in that open menu, then
              <ul><li><kbd>Enter</kbd> or <kbd>Space</kbd> invokes that menu action (which may be to   open a submenu). </li><li><kbd>Up Arrow</kbd> or <kbd>Down Arrow</kbd> keys cycle focus through the items in   that menu. </li><li><kbd>Esc</kbd> closes the open menu or submenu and returns focus to   the parent menu item. </li><li>If the menu item with focus has a submenu, pressing <kbd>Enter</kbd>, <kbd>Space</kbd>,   or the right arrow key opens the submenu and puts focus on the first   submenu item. </li></ul>
            </li><li>When a submenu is open and focus is on a menu item in that submenu:
              <ul><li><kbd>Up Arrow</kbd> or <kbd>Down Arrow</kbd> keys cycle through the submenu items   (behaves the same as open menu). </li><li><kbd>Esc</kbd> or the <kbd>Left Arrow</kbd>  key closes the submenu and returns   focus to the parent menu item. </li></ul>
            </li><li>Typing a letter (printable character) key moves focus to   the next instance of a visible node whose title begins with that printable   letter. </li><li>First item in menu bar should be in the tab order (tabindex=0). </li><li>Disabled menu items receive focus but have no action when <kbd>Enter</kbd> or <kbd>Left Arrow</kbd>/<kbd>Right Arrow</kbd> is pressed. It is important that the state of the menu   item be clearly communicated to the user. </li><li>Tabbing out of the menu component closes any open menus. </li><li>With focus on a menu item and a sub menu opened via mouse behavior, pressing   down arrow moves focus to the first item in the sub menu. </li><li>With focus on a menu item and a sub menu opened via mouse behavior, pressing   up arrow moves focus to the last item in the sub menu. </li><li>With focus on a submenu item, the user must use arrows or the <kbd>Esc</kbd>   key to progressively close submenus and move up to the parent menu   item(s). </li><li>At the top level, <kbd>Esc</kbd> key closes any sub menus and keeps   focus at the top level menu. </li></ul></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><ul><li>A menu is a container of options. The container may have a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menu"><code>menu</code></a> or   <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menubar"><code>menubar</code></a> depending on your implementation. A menubar usually remains visible   horizontally. </li><li>The menu will contain elements menuitems with roles: <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menuitem"><code>menuitem</code></a>,   <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menuitemcheckbox"><code>menuitemcheckbox</code></a>, or <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menuitemradio"><code>menuitemradio</code></a> depending on your implementation. </li><li>If activation of your menuitem produces a popup menu, then the menuitem should have   <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-haspopup"><code>aria-haspopup</code></a>  set to the ID of the corresponding menu to allow the assistive   technology to follow the menu hierarchy and assist the user in determining   context during menu navigation. </li><li><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menuitemcheckbox"><code>menuitemcheckbox</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menuitemradio"><code>menuitemradio</code></a> should set <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-checked"><code>aria-checked</code></a> to "true" when   checked. </li><li>Menu focus should be managed by the menu using tabindex or   <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-activedescendant"><code>aria-activedescendant</code></a></li><li>A menuitem within a menu or menubar may appear in the tab order only if it   is not within a popup menu. </li><li>Each menuitem should be a child of its menu or menubar in the DOM tree. </li><li>A menuitem that is not a DOM child of the menu or menubar must be referenced   by the menu or menubar using <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-owns"><code>aria-owns</code></a> and will appear in order at the end of   the list of menuitems. Therefore, authors should ensure that navigation to each menu   item follows this order. </li></ul></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><a href="http://codetalks.org/source/widgets/grid/grid.html">menu bar and   grid</a></td></tr></tbody></table>
</div>
  <hr/>
<div class="widget" id="menubutton"><h3 class="widget-name"><code>Menu Button</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p> </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><p><a href="http://codetalks.org/source/widgets/grid/grid.html" title="http://codetalks.org/source/widgets/grid/grid.html" rel="nofollow">Menubar 1</a></p></td></tr></tbody></table>
</div>
  <hr/>
<div class="widget" id="popupmenu"><h3 class="widget-name"><code>Popup Menu</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p> </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><a href="http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Menu.html" title="http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Menu.html" rel="nofollow">dojo nightly build - popup menu</a></td></tr></tbody></table>
</div>
  <hr/>
<div class="widget" id="popuphelp"><h3 class="widget-name"><code>Popup Help (aka Bubble Help)</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p> </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"> </td></tr></tbody></table>
</div>
  <hr/>
<div class="widget" id="radiobutton"><h3 class="widget-name"><code>Radio Button</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">An option in single-select list</td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li><kbd>Tab</kbd> key will enter the radio group.
              <ul><li>When tabbing into a group focus goes to the selected button. If none is   selected it goes to the top unless you are shift tabbing, in which case, focus goes to the bottom.</li><li>When tabbing into the group a second time, you should return to the point of   previous focus (which should be the one that is checked) </li><li>Pressing <kbd>Tab</kbd> again exits the radio group. </li></ul>
            </li><li><kbd>Up Arrow</kbd> and <kbd>Left Arrow</kbd>  move forward in the group </li><li><kbd>Down arrow</kbd> and  <kbd>Right Arrow</kbd> move backwards in the group. When the arrow moves focus, the button is selected. 
            </li><li><kbd>Down Arrow</kbd> at bottom should wrap to top </li><li><kbd>Up Arrow</kbd> at top should wrap to bottom </li><li><kbd>Space</kbd> selects the radio button with focus and de-selects other radio buttons in the group. </li><li><kbd>Ctrl+Arrow</kbd> moves through the options without updating   content or selecting the button. </li></ul>          </td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1">The individual option uses the role list <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#radio"><code>radio</code></a>. It is a member of a group of   radio controls, <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#radiogroup"><code>radiogroup</code></a>. </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><ul><li> <a href="http://codetalks.org/source/widgets/radio/radio1.html" title="http://codetalks.org/source/widgets/radio/radio1.html" rel="nofollow">Radio Example using CSS Background Images</a></li><li> <a href="http://codetalks.org/source/widgets/radio/radio2.html" title="http://codetalks.org/source/widgets/radio/radio2.html" rel="nofollow">Radio Example using IMG Element</a></li><li> <a href="http://codetalks.org/source/widgets/radio/radio3.html" title="http://codetalks.org/source/widgets/radio/radio3.html" rel="nofollow">Radio Example using aria-activedescendant Property</a></li></ul></td></tr></tbody></table>
</div>
  <hr/>
<div class="widget" id="richtext"><h3 class="widget-name"><code>Rich Text Editor</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">Input control that accepts free-form text as its value. </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li>The edit control is provided by the browser; it provides the keyboard support for navigating, adding, removing and   selecting text, so that behavior is not defined by the rich internet application. </li><li>The browser should also provide a keyboard mechanism   for navigating into and out of the edit control. Within most browsers the edit   control is put into the tab order of the page and can be navigated into, out of,   and through using the tab and shift-tab keys like any standard form control. </li><li>A rich text editor widget needs to provide a user   interface for interacting with the browser provided edit control. Interaction   between the user interface and editor is defined here assuming that a toolbar is   used. </li><li><kbd>Tab</kbd> and <kbd>Shift+Tab</kbd> - If not provided by the browser, the rich   text editor widget must provide a keyboard mechanism to move into and out of the   edit control. Tab and shift-tab are the recommended keystrokes. The toolbar or   other user interface component associated with the editor is placed in the tab   order immediately before the editor. To set an attribute on text within the edit   control the user sets focus into the edit control, moves the insertion point,   selects text and presses shift-tab to move focus from the editor back to the   toolbar. The user navigates through the toolbar (see toolbar behavior) to a   desired attribute and invokes that attribute. When an attribute is invoked, that   attribute is applied to the selected text in the editor and focus moves back   into the editor at the previous insertion point with the selection intact. </li><li><strong>Options:</strong>
                <ul><li>Rather than using shift-tab to move focus from within the editor to the   toolbar, another key combination could be used (alt-up arrow, ctrl-shift-letter,   etc.). This would eliminate the need to put the user interface control (in this   example a toolbar) into the tab order immediately before the editor component.   However, there are drawbacks to using a different keystroke to navigate to the   user interface:
                    <ol><li>It is not as "discoverable" as relying on the standard tab/shift-tab   behavior; </li><li>It is difficult to find key combinations which are not already captured by   the browser or assistive technology. </li><li>Focus could stay within the toolbar after the user invokes an attribute. The   user would then have to press an additional key to move focus back into the   editor. This would allow multiple attributes to be set on the current selection   without having to return back to the user interface but it would add an extra   key sequence after setting just a single attribute. Requiring a keystroke to   move focus back into the editor would also require modifying the toolbar   behavior to intercept this keystroke and to know how to set focus back to the   component (the editor) that the toolbar is associated with. </li></ol>
                  </li></ul>
            </li></ul>          
            <p>Optionally, if the developer wishes to provide the   ability to insert a tab into the document, it is recommended one of the   following methods be used.            </p>
            <ul><li>Provide indent and outdent buttons in the menu. Keyboard shortcuts to the   buttons should be <kbd>Ctrl+M</kbd> for indent and <kbd>Ctrl+Shift+M</kbd> for outdent. </li><li>Provide a button in the menu to toggle the use of <kbd>Tab</kbd> between the two modes.   If this button is used, then <kbd>Ctrl+M</kbd> is recommended as a   keyboard shortcut to toggle the button. </li></ul>            <p> </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><span class="widget-description"> Uses the WAI-ARIA role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#textbox"><code>textbox</code></a></span></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"> </td></tr></tbody></table>
</div>    
 <hr/>
<div class="widget" id="slider">
      <h3 class="widget-name"><code>Slider</code> <span class="type-indicator">(widget)</span></h3>
      <table cellspacing="0" class="widget-features"><caption>
        Characteristics:
        </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"> A slider is user input where the user selects a value from within a given range. Sliders typically have a button such that when moved will change the current value within the current range of the slider. The button must be keyboard accessible.
              It is typically  possible to add or subtract to the current value by using directional keys such  as arrow keys. </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li><kbd>Right Arrow</kbd> and <kbd>Up Arrow</kbd> increase the value of the slider.</li><li><kbd>Left Arrow</kbd> and <kbd>Down Arrow</kbd> decrease the value of the slider.</li><li><kbd>Home</kbd> and <kbd>End</kbd> move to the minimum and maximum values of the slider.</li><li><kbd>Tab</kbd> into and out of the slider.</li><li><kbd>Page Up</kbd> and <kbd>Page Down</kbd> optionally increment or decrement the slider by a given amount.</li></ul>
              <p class="note">Focus is placed on the slider.  (The visual object that the mouse user would move, also known as the thumb.) </p>
              <p class="note">Localization for right to left languages may wish to reverse the left and right arrows.</p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><p>The slider control uses the role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#slider"><code>slider</code></a> and the role as well as its states and properties must be applied to the element that has focus. The slider must support the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuenow"><code>aria-valuenow</code></a>, <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuemax"><code>aria-valuemax</code></a>, and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuemin"><code>aria-valuemin</code></a> properties. If the valuenow property should be provided in a more human readable form than a decimal, such as a day of the week, then the slider should provide that information using <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuetext"><code>aria-valuetext</code></a>. </p>
              <p>Sliders should be labelled and a reference to the label should be provided using <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a>.</p></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><ul><li> <a href="http://codetalks.org/source/widgets/slider/simple-slider.html" title="http://codetalks.org/source/widgets/slider/simple-slider.html" rel="nofollow">Simple slider</a></li><li> <a href="http://codetalks.org/source/widgets/slider/pretty-slider-background-images.html" title="http://codetalks.org/source/widgets/slider/pretty-slider-background-images.html" rel="nofollow">Pretty slider</a></li><li> <a href="http://mindtrove.info/html/rating-tutorial.html" title="http://mindtrove.info/html/rating-tutorial.html" rel="nofollow">MINDTROVE Rating Widget</a></li><li> <a href="http://www.paciellogroup.com/blog/misc/ARIA/slider/" title="http://www.paciellogroup.com/blog/misc/ARIA/slider/" rel="nofollow">Paciello Group slider</a></li></ul>
            <p>Please note that not all examples work in all browser and version combinations. For example, note the compatibility statement.</p></td></tr></tbody></table>
  </div>
    <hr/>
    <div class="widget" id="slidertwothumb">
      <h3 class="widget-name"><code>Slider (Multi-Thumb)</code> <span class="type-indicator">(widget)</span></h3>
      <table cellspacing="0" class="widget-features"><caption>
        Characteristics:
        </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"> A multi-thumb slider is a slider with multiple user inputs designed to change the maximum and minimum range for an object it controls.</td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p>This range slider allows author to modify the maximum and minimum range of an object  within an applications. Moving the thumb on either end allows the author to modify the corresponding maximum or minimum value of what it is controlling.</p>
              <ul><li><kbd>Tab</kbd> to the first slider thumb.</li><li>Second <kbd>Tab</kbd> moves to next slider thumb..</li><li>Third <kbd>Tab</kbd> moves to the next slider thumb or if there are no   more, it moves to the next tab stop on the page. </li><li><kbd>Shift+Tab</kbd> moves backwards through the tabs.</li><li>With focus on a thumb: Same as <a href="#slider">Slider</a> above.
                  <ul><li><kbd>Right Arrow</kbd> and <kbd>Up Arrow</kbd> increase the value of the slider constrained by the value of the other thumb. </li><li><kbd>Left Arrow</kbd> and <kbd>Down Arrow</kbd> decrease the value of the slider constrained by the value of the other thumb. </li><li><kbd>Home</kbd> and <kbd>End</kbd> move to the minimum and maximum values of the slider constrained by the value of the other thumb. </li><li><kbd>Page Up</kbd> and <kbd>Page Down</kbd> optionally increment or decrement the   slider by a given amount, constrained by the value of the other thumb. </li></ul>
                </li></ul>
              <p class="note">Focus is placed on one of the thumbs of the slider.</p>
              <p class="note">All thumbs are in the tab order.</p>
              <p class="note">Localization for right to left languages may wish to reverse the left and right arrows.</p>
              <p class="note">If the current value of a slider crosses over one of the other sliders, the tab order remains the same.  Example.  If a high range slider is moved so that its current value is below the current value of a low range slider, the thumb will visually appear to be before the low range slider.  This should not change the tab order of the slider. </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><p>Each thumb  uses the role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#slider"><code>slider</code></a> . The thumb must support the <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuenow"><code>aria-valuenow</code></a>, <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuemax"><code>aria-valuemax</code></a>, and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuemin"><code>aria-valuemin</code></a> properties. If the valuenow property should be provided in a more human readable form than a decimal, such as a day of the week, then the slider should provide that information using <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuetext"><code>aria-valuetext</code></a>. Each thumb should define a <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> relationship between it and the opposing slider thumb as  this will effect the corresponding <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuenow"><code>aria-valuenow</code></a>, <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuemax"><code>aria-valuemax</code></a>, and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuemin"><code>aria-valuemin</code></a> properties. Each slider thumb should define a <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> relationship between the thumb and the object it is controlling (the maximum or minimum value).</p>
              <p>Sliders should be labelled and a reference to the label should be provided using <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a>.</p>
              <p>Finally, if your range slider also controls a live area you should establish the controls relationship between each slider button (upper and lower) and the live area you it is controlling.</p></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><ul><li><a href="http://codetalks.org/source/widgets/slider/pretty-slider-dual-inline-img.html" title="http://codetalks.org/source/widgets/slider/pretty-slider-dual-inline-img.html" rel="nofollow">Multi-Thumb Slider Example using inline images for thumbs</a></li><li><a href="http://www.paciellogroup.com/blog/misc/samples/aria/slider/doubleslider.html" title="http://www.paciellogroup.com/blog/misc/samples/aria/slider/doubleslider.html" rel="nofollow">TPG double slider</a></li></ul>
            <p> </p></td></tr></tbody></table>

</div>
<hr/>
  <div class="widget" id="spinbutton">
    <h3 class="widget-name"><code>Spinbutton</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">Range with which a user selects from amongst discrete choices. 
          A spinbutton typically allows the user to select from the given range through   the use of an up and down button on the keyboard. Visibly, the current value is   incremented or decremented until a maximum or minimum value is reached. </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li><kbd>Right Arrow</kbd> and <kbd>Up Arrow</kbd> increase the value. </li><li><kbd>Left Arrow</kbd> and <kbd>Down Arrow</kbd> decrease the value. </li><li><kbd>Home</kbd> and <kbd>End</kbd> key  move to the maximum or minimum values </li><li>Optional <kbd>Page Up</kbd> and <kbd>Page Down</kbd> incrementally increase or   decrease the value </li><li><kbd>Tab</kbd> key moves into and out of the widget </li></ul>          
            <p class="note">Focus should remain on the edit field </p>
          <p class="note">Localization for right to left languages may wish to   reverse the left and right arrows. </p>         </td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#spinbutton"><code>spinbutton</code></a> is a child of both 
            <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#composite"><code>composite</code></a> 
          and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#range"><code>range</code></a>. It requires current, minimum, and maximum values be set with the WAI-ARIA properties 
          <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuenow"><code>aria-valuenow</code></a>, <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuemin"><code>aria-valuemin</code></a>, and <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-valuemax"><code>aria-valuemax</code></a>.      </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><p><a href="http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Spinner.html" title="http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Spinner.html" rel="nofollow">dojo nightly build</a></p></td></tr></tbody></table>
  </div>
  <hr/>
  <div class="widget" id="tabpanel">
    <h3 class="widget-name"><code>Tab Panel</code> <span class="type-indicator">(widget)</span></h3>
         <table cellspacing="0" class="widget-features"><caption>
          Characteristics:
          </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"><p>A tabbed interface component is a container for resources associated with a tab. It is a set of layered pages where only one page is displayed at a time. The general look is similar to a file folder with a "tab" that contains the title of the folder. The tabs are arranged along one of the edges of the contents but most commonly are found at the top of the page. The user navigates and makes the contents of each page visible by interacting with the title "tab" of the page. Sometimes referred to as a tab container or tab panel. Terms for understanding Tab Panels include:</p>
                <dl><dt>tabbed interface component</dt><dd> a set of tabs and associated tab panels </dd><dt>tab panel</dt><dd>contents area that is associated with a tab</dd><dt>tab</dt><dd>the label/title area of the tab panel. This is where you click to activate a tab panel </dd><dt>tablist</dt><dd>the set of tabs</dd></dl>
                <p>When the user activates a tab, the contents of the corresponding tab panel is made visible. The tab is considered "active". The tab remains active until another tab is activated. The active tab is placed into the tab order. Only the active tab should be in the tab order. A default tab is specified that is active when the tabbed interface component is initialized. A collection of tabs and their associated tab panels is a complex widget, because it performs show/hide actions as well as moving the user's point of regard around within the content. </p></td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li> <kbd>Tab</kbd> - only the active tab is in the tab order. The user reaches the tabbed  panel component by pressing the tab key until the active tab title  receives focus. </li><li><kbd>Left Arrow</kbd> - with focus on a tab, pressing the left arrow will move focus to the  previous tab in the tab list and activate that tab. Pressing the left  arrow when the focus is on the first tab in the tab list will move  focus and activate the last tab in the list. </li><li><kbd>Right Arrow</kbd> - with focus on a tab, pressing the right arrow will move focus to the  next tab in the tab list and activate that tab. Pressing the right  arrow when the focus is on the last tab in the tab list will move focus  to and activate the first tab in the list. </li><li><kbd>Up arrow</kbd> - behaves the same as left arrow in order to support vertical tabs </li><li><kbd>Down arrow</kbd> - behaves the same as right arrow in order to support vertical tabs </li><li><kbd>Ctrl+Up Arrow</kbd> - with focus anywhere within the tab panel, pressing <kbd>Ctrl+Up Arrow</kbd>  will  move focus to the tab for that panel. This is not standard behavior -  is this something we want to implement? Is it necessary if we provide a  mechanism to change the active tab? Similar to  <kbd>Ctrl+PageUp</kbd>/<kbd>Ctrl+PageDown</kbd> in  Firefox to switch tabs? </li><li> <kbd>Alt+Del</kbd> - When deletion is allowed, with focus anywhere within the tab panel,  pressing alt-del will delete the current tab and tab panel from the  tabbed interface control. If additional tabs remain in the tabbed  interface, focus goes to the next tab in the tab list. An alternative  to providing a keystroke to close a tab is to provide a context menu  that is associated with the tab title. When focus is on the tab,  pressing <kbd>Shift+F10</kbd> or pressing the right mouse button will open a  context menu with the close choice </li><li> <kbd>Ctrl+PageUp</kbd> - When focus is inside of a tab panel, pressing <kbd>Ctrl+PageUp</kbd> moves focus  to the tab of the previous tab in the tab list and activates that tab.  When focus is in the first tab panel in the tab list, pressing  <kbd>Ctrl+PageUp</kbd> will move focus to the last tab in the tab list and  activate that tab. </li><li><kbd>Ctrl+PageDown</kbd> When focus is inside of a tab panel, pressing <kbd>Ctrl+PageDown</kbd> moves  focus to the tab of the next tab in the tab list and activates that  tab. When focus is in the last tab panel in the tab list, pressing  <kbd>Ctrl+PageUp</kbd>will move focus to the first tab in the tab list and  activate that tab. </li></ul>
                <p>Regarding <kbd>Ctrl+PageUp</kbd>/<kbd>Ctrl+PageDown</kbd>. This is currently implemented in Firefox to move  between browser tabs. Firefox also supports <kbd>Ctrl+Tab</kbd> and <kbd>Ctrl+Shift+Tab</kbd>  to move between tabs. Internet Explorer 7 also uses <kbd>Ctrl+Tab</kbd> and  <kbd>Ctrl+Shift+Tab</kbd>. There may be advantages to using <kbd>Ctrl+PageUp</kbd>/<kbd>Ctrl+PageDown</kbd> as the keys to change tabs since it is a recognizable keystroke to at  least Firefox users and is also supported by the Windows operating  system to move between panels in a tabbed dialog. The problem is that  if the user is within a tabbed interface control on a Web page, they  can not easily switch browser tabs without first moving focus outside  of the tabbed interface control. This may be acceptable. The other  issue is if the entire Web page is a tabbed interface control - in that  case the user could not ever switch browser tabs unless the control on  the Web page ignored the <kbd>Ctrl+PageUp</kbd>/<kbd>Ctrl+PageDown</kbd> keypress (and thus  letting the browser access it) when the first or last tab was reached. </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><ul><li> The tabbed interface component uses the  role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tabpanel"><code>tabpanel</code></a>. </li><li> The tabbed panel contains tabs and their panels. An element with role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tab"><code>tab</code></a> is used as a grouping label, providing a link for selecting the tabcontent to be rendered to the user. </li><li>The tabbed panel should manage the selected state of each tab by maintaining its <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-selected"><code>aria-selected</code></a> state. </li><li> A <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tablist"><code>tablist</code></a> is the container role for a set of elements with the role attribute set to <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tab"><code>tab</code></a>. </li></ul></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><ul><li><a href="http://codetalks.org/source/widgets/tabpanel/tabpanel1.html">Simple tab panel</a> </li><li><a href="http://codetalks.org/source/widgets/tabpanel/tabpanel.html">Another tab panel</a></li></ul>              </td></tr></tbody></table>
  </div>
      <hr/>
  <div class="widget" id="toolbar">
    <h3 class="widget-name"><code>Tool Bar</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"><p>A <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#toolbar"><code>toolbar</code></a> is a flat non-hierarchical collection of controls that provides quick access to a subset of the functions found in the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menubar"><code>menubar</code></a>/<a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menu"><code>menu</code></a> hierarchy.  Its purpose is to reduce effort in using these functions.  There should neither be too few nor too many controls within a toolbar.  When creating toolbars try to limit the number of items to approximately seven, as forcing users to navigate through an excessive number of items is a usability concern. Since navigation between toolbars is accomplished using a <kbd>Tab</kbd> keystroke, too few controls within a toolbar also creates a usability issue as it requires numerous <kbd>Tab</kbd> keystrokes to navigate between toolbars.</p><p>Authors must supply an <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-label"><code>aria-label</code></a> property on each toolbar when their application contains more than one toolbar. The label provides information about the purpose of each toolbar; for example, an "Edit" toolbar that contains cut, copy, paste, clear, undo, and redo controls.  If the application has many toolbars, it is recommended that they be placed inside a container element with a role of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#group"><code>group</code></a> to allow for keyboard navigation to the entire collection of toolbars.  It is further recommended that authors provide access to these functions via a <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menubar"><code>menubar</code></a> and <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menu"><code>menu</code></a>s to avoid cluttering the user interface with a surplus of toolbars.</p></td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li><kbd>Tab</kbd> moves focus to the first enabled toolbar button. </li><li>A subsequent <kbd>Tab</kbd> moves focus out of the toolbar </li><li><kbd>Left Arrow</kbd> and <kbd>Right Arrow</kbd> keys navigate to the enabled buttons   in the toolbar </li></ul>          
            <p class="note">Direction may need to be adjusted for Right to Left   languages </p>
            <p class="note">There is debate concerning the treatment of disabled toolbar buttons -- should they be focusable or not?  Visually, disbled buttons are grayed-out, and typicially not placed in the <kbd>tab</kbd> order.  This invites an issue about how a screen reader user discovers these buttons if they are not keyboard navigable.  Several ways of handling this include:</p>
            <ul><li>In software applications like Microsoft® Word, the toolbars themselves are not reachable by the   keyboard user, but the features are available on one of the drop-down menus. </li><li>Users set a preference indicating whether they want disabled buttons focusable.</li><li>Disabled buttons are not focusable until they are enabled.  This is the way tool bars currently work.</li><li>Disabled buttons are focusable, but read by the screen reader as disabled.</li></ul></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1">The <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#toolbar"><code>toolbar</code></a> is a child of <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#group"><code>group</code></a>. </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><a href="http://wiki.codetalks.org/wiki/index.php/Set_of_ARIA_Test_Cases#Toolbar">Toolbar with WAI-ARIA live region</a></td></tr></tbody></table>
  </div>
  <hr/>
  <div class="widget" id="tooltip">
    <h3 class="widget-name"><code>Tooltip Widget</code> <span class="type-indicator">(widget)</span></h3>
     <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">Popup that displays a description for an element when a user passes over or   rests on that element. Supplement to the normal tooltip processing of the user   agent. It should popup automatically when the user gives input focus to the widget or   element with which it is associated. The tooltip widget can be dismissed by pressing the ESC   key or by other methods noted below. The tooltip widget differs from the <a href="#dialog_tooltip">Dialog (Tooltip)</a> in that it does not receive focus at   any time. </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p><kbd>Esc</kbd>: Dismisses the Tooltip. </p>
		  	<p class="note">Note: The trigger element to which the tooltip is attached,   e.g., a link, should never actually lose input focus. </p>
		  	<p class="note">Note: If the tooltip is invoked when the trigger element   gets focus, then it should be dismissed when it no longer has focus (onBlur). If   the tooltip is invoked with mouseIn, then it should be dismissed with a   mouseOut. </p>		  	
		  	<p class="note">Note: If more then one widget uses the same keys, e.g.,   Esc, then they should be handled in a Last In First Out (LIFO) manner. For example, an editable grid contains gridcells which contain date fields. The user invokes Actionable mode on the grid and then interacts with the Date Field to invoke the Date Picker. At this point the first press of the Escape key will close the Date Picker, the second press will exit Actionable mode and return to Navigation mode.</p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1">Uses the WAI-ARIA role <span class="widget-description"><a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tooltip"><code>tooltip</code></a></span></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><a href="http://codetalks.org/source/widgets/tooltip/tooltip.html">Simple tooltip</a></td></tr></tbody></table>
 </div>
  <hr/>
  <div class="widget" id="treegrid">
    <h3 class="widget-name"><code>Tree Grid</code> <span class="type-indicator">(widget)</span></h3>
    <table cellspacing="0" class="widget-features"><caption>
Characteristics:
    </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">A grid whose rows can be expanded and collapsed in the same manner as for a tree. A Tree Grid is a combination of a Treeview and a Table with rows that are   expandable</td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p>There are two modes of keyboard interaction: </p>
          <ul><li>Navigation Mode (Read-Only) is the default mode, and allows quick   and intuitive navigation around the grid.
              <ul><li><kbd>Tab</kbd>
    
                  <ul><li>The initial tab enters the grid with focus on the first cell of the first row, often a header. </li><li>Once in the grid a second tab moves out of the grid to the next tab stop. </li><li>Once focus is established in the grid, a <kbd>Tab</kbd> into or a <kbd>Shift+Tab</kbd> into the   grid will return to the cell which last had focus. </li></ul>
    
                </li><li><kbd>Left Arrow</kbd> and <kbd>Right Arrow</kbd> keys  navigate between columns. If the   next cell in the row is empty, focus should not move. </li><li><kbd>Up Arrow</kbd> and <kbd>Down Arrow</kbd> The down arrow moves focus to the first column of a child row, if expanded. Otherwise focus is moved to the same column in the next row. Up arrow performs the same navigation but in reverse. </li><li><kbd>Ctrl+Left</kbd> and <kbd>Ctrl+Right Arrows</kbd> expand or collapse rows. </li><li>If the cell contains an editable field, the <kbd>Enter</kbd> key starts edit mode and the <kbd>Esc</kbd> key exits edit mode. </li><li>Selecting Cells
                  <ul><li><kbd>Ctrl+Space</kbd> selects the current column. </li><li><kbd>Shift+Space</kbd> selects the current row. </li><li><kbd>Ctrl+A</kbd> selects the entire grid. </li><li><kbd>Shift+Arrow</kbd> selects contiguous cells. </li><li><kbd>Shift+F8</kbd> Allows additional cells to be added to a   previous selection to accomplish non-contiguous selection. </li></ul>
</li></ul>
            </li></ul>
          
          <p class="note">Note: The author may choose to indent child nodes visually. This should be done with an appropriate number of spacer cells marked as presentation in order to keep the headers aligned. </p>
          
          <p class="note">Note: If cells are used for padding or layout of the hierarchy, navigation to those presentational cells should be prevented. </p>
          
          <ul><li>Actionable Mode (Interactive) allows the interaction with other   objects that might be found in the grid cells such as edit fields, links,   etc.
              <ul><li><kbd>F2</kbd> pressed anywhere inside the grid will enter Actionable   Mode. Focus will not be moved. </li><li><kbd>Enter</kbd> pressed while focus is on an actionable item will   enter Actionable Mode. Focus will remain on the actionable item that has focus. </li><li>Optionally, alphanumeric keys pressed while focus is on an   actionable item will enter Actionable Mode. Focus will remain on the actionable   item that has focus. </li><li>Using grid as an example, by default, pressing <kbd>Esc</kbd> anywhere inside the grid will mean exiting Actionable mode (by which the user may enter text or perform an action to complete a operation) and a return to Navigation Mode (where the user is allowed to move focus among elements). If a widget is in the current grid cell that also uses the <kbd>Esc</kbd> key, then it should cancel the event propagation. A subsequent press of the <kbd>Esc</kbd> key will return focus to the parent widget.</li><li><kbd>Tab</kbd> will move to the next actionable (tabbable) item in the   grid and stay within the grid wrapping at the bottom. In this mode each tabbable   object in each cell of the grid can be reached with the tab key. If multiple   tabbable items are located inside a single grid cell, the tab will stop at each   one. When the last tabbable item in a cell is reached the next tab will move to   the next tabbable item in the grid, wrapping at the last tabbable item in the   grid. </li><li><kbd>Shift+Tab</kbd> moves to the previous actionable (tabbable) item   in the grid and stays within the grid, wrapping at the top. </li></ul>
            </li></ul>
     </td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><p>Uses the WAI-ARIA role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treegrid"><code>treegrid</code></a>, and requires the child element <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#row"><code>row</code></a>. By default a treegrid is considered to be editable, meaning all gridcells     are editable. </p>
          <ul><li>To make a treegrid read-only, set <code>aria-readonly="true"</code> on the document element having a     <code>role="treegrid."</code> This will make all gridcells read-only. </li><li>To override the read-only status on an individual     gridcell, set its <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-readonly"><code>aria-readonly</code></a> property to false. </li></ul>          </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><ul><li><a href="http://codetalks.org/source/widgets/treegrid/treegrid.sample.html" title="http://codetalks.org/source/widgets/treegrid/treegrid.sample.html" rel="nofollow">Grid with expandable cells</a></li><li><a href="http://codetalks.org/source/widgets/treegrid/treegrid.html" title="http://codetalks.org/source/widgets/treegrid/treegrid.html" rel="nofollow">Grid with one expandable cell</a></li><li>For a visual (not accessible) example of where padding cells have been implemented see: <a href="http://download.dojotoolkit.org/release-1.4.1/dojo-release-1.4.1/dojox/grid/tests/test_treegrid.html" rel="nofollow">dojo's TreeGrid example</a>. </li><li>An example where padding cells have not been used (also not accessible): <a href="http://jdevadf.oracle.com/adf-richclient-demo/faces/components/treeTable.jspx" rel="nofollow">Oracle's Tree Grid</a>. </li></ul></td></tr></tbody></table>
  </div>
  <hr/>
  <div class="widget" id="TreeView">
		<h3 class="widget-name"><code>Tree View</code> <span class="type-indicator">(widget)</span></h3>
  	<table class="widget-features" cellspacing="0"><caption>
				Characteristics:
			</caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1"><p>A
						tree view is a component to navigate hierarchical lists. It is made up
						of one or more top level nodes. A node may have children or it may be
						an end node. Nodes with children can be expanded or collapsed - when
						expanded its child nodes are visible. When collapsed the children are
						not visible. There is generally some sort of visual indication whether
						a node has children and can be expanded. Any number of nodes can be
						expanded at a time and child nodes may contain children. </p>
							<p>A
								tree node is commonly used to navigate the directories and files on a
								file system. The directory nodes can be expanded and collapsed to
								reveal its contained subdirectories and files. Terms for understanding
								tree views include:</p>
						<dl><dt>node</dt><dd>An item in a tree. </dd><dt>parent node</dt><dd>Node with children. It can be opened / expanded or closed / collapsed </dd><dt>open node</dt><dd>Expanded node with children; first-level children are visible. </dd><dt>closed node</dt><dd>Closed node with children; the children are not visible. </dd><dt>end node</dt><dd>Node with no children </dd></dl>
						<p>General behavior for tree views follows:</p>
						<ul><li>On first load of the tree component, the top level node is in the tab order. </li><li>One and only one node of the tree component is in the tab order of the page at any time. </li><li>The last visited node in the tree control is retained in the tab order when the user navigates away from the tree control. </li><li>Nodes can be focused and/or selected. There must be visual distinction between focused and selected nodes. </li><li>Arrowing
								to an item with the keyboard or clicking on an item with the mouse will
								focus and select the node. Any previous selections are cleared </li></ul></td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><ul><li> <kbd>Up Arrow</kbd> and <kbd>Down arrow</kbd> keys move between visible nodes. </li><li> <kbd>Left arrow</kbd> key on an expanded node closes the node. </li><li> <kbd>Left arrow</kbd> key on a closed or end node moves focus to the node's parent. </li><li> <kbd>Right arrow</kbd> key expands a closed node, moves to the first child of an open node, or does nothing on an end node. </li><li> <kbd>Enter</kbd> key performs the default action on end nodes. </li><li> Typing a letter key moves focus to the next instance of a visible node whose title begins with that letter. </li><li> <kbd>Home</kbd> key moves to the top node in the tree view. </li><li> <kbd>End</kbd> key moves to the last visible node in the tree view. </li><li> <kbd>Ctrl+Arrow</kbd> to an item with the keyboard focuses the item (but does not select it). Previous selections are maintained, provided that the <kbd>Ctrl</kbd> key is not released or that some other keyboard function is not performed. </li><li> <kbd>Ctrl+Space</kbd> with focus on an item toggles the selection of the item. </li><li> <kbd>Shift+Up Arrow</kbd> extends selection up one node. </li><li> <kbd>Shift+Down Arrow</kbd> extends selection down one node. </li><li> <kbd>Shift+Home</kbd> extends selection up to the top-most node. </li><li> <kbd>Shift+PageDown</kbd> extends selection down to the last node. </li><li> <kbd>*</kbd>(asterisk) on keypad expands all nodes. </li></ul></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1">A tree view uses the WAI-ARIA role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#tree"><code>tree</code></a>,
						where tree is a main container element. A tree can itself contain
						subtrees that may be collapsed and expanded; these have the role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#treeitem"><code>treeitem</code></a>. A collection of treeitems to be expanded and collapsed are enclosed in a group. See the XHTML example in the <cite><a href="http://www.w3.org/TR/wai-aria/">WAI-ARIA</a></cite> [<cite><a href="#ref_ARIA">ARIA</a></cite>] specification.</td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><ul><li> <a href="http://codetalks.org/source/widgets/tree/tree.html" title="http://codetalks.org/source/widgets/tree/tree.html" rel="nofollow">Simple tree</a></li><li> <a href="http://codetalks.org/source/widgets/tree/tree3.html" title="http://codetalks.org/source/widgets/tree/tree3.html" rel="nofollow">Tree</a></li></ul></td></tr></tbody></table>
  	</div>
  <hr/>
  <div class="widget" id="windowsplitter">
    <h3 class="widget-name"><code>Window Splitter</code> <span class="type-indicator">(widget)</span></h3>
     <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">Visible separator between sections of a Window which can be used to modify the   size of the panes</td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p>A Window Splitter can take one of two forms, namely, fixed size and variable size.
              </p>
            <ul><li><kbd>Tab</kbd> - Like other widgets, the tab key is used to move focus   to the splitter. It should appear in the normal tab order of the page. A second   tab will move focus to the next tabbable item on the page. </li><li><kbd>Left Arrow</kbd> and <kbd>Right Arrow</kbd> - In the case of a vertical splitter these keys will move the splitter to the left and to the right.</li><li><kbd>Up Arrow</kbd> and <kbd>Down Arrow</kbd> - In the case of a horizontal splitter these keys will move the splitter up and down.</li><li><kbd>End</kbd> - Moves splitter to the maximum size of the region. </li><li><kbd>Home</kbd> - Moves splitter to the minimum size of the region. </li><li><kbd>Enter</kbd> Restore splitter to previous position (undo Home or End). </li><li><kbd>F6</kbd> Optionally is recommended to rotate through the window   panes. </li><li><kbd>Ctrl+F6</kbd> Optionally brings focus directly to the   splitter. Pressing <kbd>Control+F6</kbd> again would rotate forward through additional   splitters located on the page. </li><li><kbd>Shift+Ctrl+F6</kbd> optionally reverses the direction   rotating backwards through additional splitters located on the page. </li></ul>
            
          <p class="note">Note: Fixed size splitter simply omits implementation of the arrow keys. </p>
          <p class="note">Note: The group recommends unique naming of the window   splitter to avoid the confusion that could be created by multiple splitters   located on the same window. </p>
          <p class="note">Note:  The group recommends that a splitter "default position restore" option be available in a context menu. </p>
          <p> </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"><p>Uses the WAI-ARIA role <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#separator"><code>separator</code></a>.  and requires the child element <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#row"><code>row</code></a>. By default a treegrid is considered to be editable, meaning all gridcells are editable.</p>
          	<ul><li>Most window splitters are expandable and collapsible. When it is, ensure that the <a class="state-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-expanded"><code>aria-expanded</code></a> state is maintained.</li><li>As there may be multiple splitters make sure that you 
          			set <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-label"><code>aria-label</code></a>, the <code>title</code> attribute, or provide an <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-labelledby"><code>aria-labelledby</code></a> relationship to label text on the splitter to ensure that an accessible name may be computed by the user agent. This will allow the assistive technology to convey to the user which window splitter is being operated.</li><li>Author should apply <a class="property-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/states_and_properties#aria-controls"><code>aria-controls</code></a> to the element having the <a class="role-reference" href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#separator"><code>separator</code></a> role. It's values should be the IDs of the panels it controls. This way an assistive technology may navigate to the pane it controls. If no panel exists (it disappears from the DOM) no ID reference is needed for that panel.</li></ul></td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"><a href="http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/layout/test_BorderContainer.html">Window splitter</a></td></tr></tbody></table>
 </div>
  <hr/>
  <div class="widget" id="wizard">
    <h3 class="widget-name"><code>Wizard</code> <span class="type-indicator">(widget)</span></h3>
     <table cellspacing="0" class="widget-features"><caption>
      Characteristics:
      </caption><tbody><tr><td class="widget-description-head" scope="row" rowspan="1" colspan="1">Description: </td><td class="widget-description" rowspan="1" colspan="1">A sequence of dialogs or panels guiding the user through performing a task. </td></tr><tr><td class="widget-keyboard-head" scope="row" rowspan="1" colspan="1">Keyboard Interaction: </td><td class="widget-keyboard" rowspan="1" colspan="1"><p>A Wizard can be done in several ways. Either is valid. </p>
            <ul><li>Method 1: Like a <a href="#toolbar">Tool Bar</a> </li><li>Method 2: Controls as Default Actions
                <ul><li><kbd>Esc</kbd> cancels the wizard. </li><li><kbd>Enter</kbd> invokes the "next" action; If the last   page, it invokes "finish" </li></ul>
              </li><li>Method 3: Hot Keys
                <ul><li><kbd>Ctrl+Alt+N</kbd> next, finish </li><li><kbd>Ctrl+Alt+P</kbd> previous </li><li><kbd>Esc</kbd> cancel, exit without saving </li><li><kbd>Ctrl+Alt+R</kbd> reset current page to default settings </li><li><kbd>Ctrl+Alt+S</kbd> save and exit </li></ul>
              </li><li>Method 4: Like a <a href="#dialog_nonmodal">Dialog</a> </li></ul>            <p> </p></td></tr><tr><td class="widget-aria-head" scope="row" rowspan="1" colspan="1">WAI-ARIA Roles, States, and Properties: </td><td class="widget-aria" rowspan="1" colspan="1"> </td></tr><tr><td class="widget-example-head" scope="row" rowspan="1" colspan="1">Example: </td><td class="widget-example" rowspan="1" colspan="1"> </td></tr></tbody></table>
 </div>
</div>
<div class="section" id="reuse_comp_lib">
  <h2><span class="tocnum">11. </span>  Reusable Component Libraries </h2>
  <p>Rich internet applications are complex to author. To save time, it is often faster to use existing widget libraries that implement WAI-ARIA and that have already gone through:</p>
  <ul><li> extensive assistive technology testing</li><li>cross browser testing</li><li>testing to ensure that the widgets respond to desktop settings</li><li>testing to ensure that the widgets match a common keyboard style guide</li></ul>
  <p>Some publicly available UI component libraries have already implemented WAI-ARIA. Authors can reuse such libraries to start developing accessible rich internet applications.</p>
</div>
<div class="section" id="appendices">
  <h2><span class="tocnum">12. </span> Appendices</h2>
  <div class="section" id="references">
	<h3><span class="tocnum">12.1. </span> References</h3>
	<p>This section is <em>informative</em>.</p>
		<p>Resources referenced informatively provide useful information relevant to this document, but do not comprise a part of its requirements.</p>
		<dl><dt><a id="ref_ARIA" name="ref_ARIA"></a>[ARIA]</dt><dd><cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-20100916/">Accessible
			Rich Internet Applications (<acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym>) 1.0</a></cite>. J. Craig,
			M. Cooper, L. Pappas, R. Schwerdtfeger, L. Seeman, Editors,
			W3C Working Draft (work in progress), 16 September 2010. This version
			of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> is
			available at http://www.w3.org/TR/2010/WD-wai-aria-20100916/. <a href="http://www.w3.org/TR/wai-aria/">Latest
				version of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym></a> available
			at http://www.w3.org/TR/wai-aria/.</dd>
		<dt><a id="ref_ARIA-PRIMER" name="ref_ARIA-PRIMER"></a>[ARIA-PRIMER]</dt><dd><cite><a href="http://www.w3.org/TR/2010/WD-wai-aria-primer-20100916/"><acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> 1.0
			      Primer</a></cite>. L. Pappas, R. Schwerdtfeger, M. Cooper, Editors,
			      W3C Working Draft (work in progress), 16 September 2010. This version
			      of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> Primer is available at http://www.w3.org/TR/2010/WD-wai-aria-primer-20100916/. <a href="http://www.w3.org/TR/wai-aria-primer/">Latest
			      version of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> Primer</a> available at http://www.w3.org/TR/wai-aria-primer/. </dd><dt><a id="ref_ARIA-ROADMAP" name="ref_ARIA-ROADMAP"></a>[ARIA-ROADMAP]</dt><dd><cite><a href="http://www.w3.org/TR/2008/WD-wai-aria-roadmap-20080204/">Roadmap for Accessible Rich Internet Applications (<acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> Roadmap)</a></cite>, R. Schwerdtfeger, Editor, W3C Working Draft (work in progress), 4 February 2008. This version of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> Roadmap is available at http://www.w3.org/TR/2008/WD-wai-aria-roadmap-20080204/. <a href="http://www.w3.org/TR/wai-aria-roadmap/">Latest version of <acronym title="Accessible Rich Internet Applications">WAI-ARIA</acronym> Roadmap</a> available at http://www.w3.org/TR/wai-aria-roadmap/.</dd><dt><a class="normref" id="ref_DOM" name="ref_DOM"></a>[DOM]</dt><dd><cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/">Document Object Model (DOM) Level 2 Core Specification</a></cite>, L. Wood, G. Nicol, A. Le Hors, J. Robie, S. Byrne, P. Le Hégaret, M. Champion, Editors, W3C Recommendation, 13 November 2000, http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/. <a href="http://www.w3.org/TR/DOM-Level-2-Core/" title="Latest version of Document Object Model (DOM) Level 2 Core Specification">Latest version of DOM Core</a> available at http://www.w3.org/TR/DOM-Level-2-Core/.</dd></dl>
</div>
  <div class="section" id="acknowledgements">
	<h3><span class="tocnum">12.2. </span> Acknowledgments</h3>
	<p>The following people contributed to the development of this document.</p>
	<div class="section" id="ack_group">
		<h4><span class="tocnum">12.2.1. </span> Participants in the PFWG at the time of publication</h4>
		<ol><li>David Bolter (Invited Expert, University of Toronto Adaptive Technology Resource Centre) </li><li>Sally Cain (Royal National Institute of Blind People)</li><li>Ben Caldwell (Invited Expert, Trace)</li><li>Charles Chen (Google, Inc.) </li><li>Michael Cooper (W3C/MIT)</li><li>James Craig (Apple, Inc.) </li><li>Dimitar Denev (Frauenhofer Gesellschaft)</li><li>Steve Faulkner (Invited Expert, The Paciello Group) </li><li>Kentarou Fukuda (IBM Corporation)</li><li>Andres Gonzalez (Adobe Systems Inc.)</li><li>Georgios Grigoriadis (SAP AG) </li><li>Jon Gunderson (Invited Expert, UIUC)</li><li>Markus Gylling (DAISY Consortium)</li><li>Sean Hayes (Microsoft Corporation)</li><li>John Hrvatin (Microsoft Corporation) </li><li>Kenny Johar (Vision Australia) </li><li>Masahiko Kaneko (Microsoft Corporation) </li><li>Matthew King (IBM Corporation)</li><li>Diego La Monica (International Webmasters Association / HTML Writers Guild (IWA-HWG)) </li><li>Gez Lemon (International Webmasters Association / HTML Writers Guild (IWA-HWG))</li><li>Thomas Logan (HiSoftware Inc.)</li><li>William Loughborough (Invited Expert)</li><li>Anders Markussen (Opera Software) </li><li>Matthew May (Adobe Systems Inc.) </li><li>Shane McCarron (Invited Expert, Aptest)</li><li>Charles McCathieNevile (Opera Software)</li><li>James Nurthen (Oracle Corporation) </li><li>Joshue O'Connor (Invited Expert) </li><li>Artur Ortega (Yahoo!, Inc.)</li><li>Simon Pieters (Opera Software) </li><li>T.V. Raman (Google, Inc.) </li><li>Gregory Rosmaita (Invited Expert)</li><li>Tony Ross (Microsoft Corporation)</li><li>Janina Sajka (Invited Expert, The Linux Foundation)</li><li>Martin Schaus (SAP AG) </li><li>Joseph Scheuhammer (Invited Expert, Inclusive Design Research Centre, OCAD University) </li><li>Stefan Schnabel (SAP AG) </li><li>Richard Schwerdtfeger (IBM Corporation)</li><li>Lisa Seeman (Invited Expert, Aqueous) </li><li>Cynthia Shelly (Microsoft Corporation) </li><li>Andi Snow-Weaver (IBM Corporation)</li><li>Henny Swan (Opera Software)</li><li>Gregg Vanderheiden (Invited Expert, Trace)</li><li>Léonie Watson (Invited Expert, Nomensa)</li><li>Gottfried Zimmermann (Invited Expert, Access Technologies Group)</li></ol>
  </div>
	<div class="section" id="ack_others">
		<h4><span class="tocnum">12.2.2. </span> Other previously active PFWG participants and other contributors to the Accessible Rich Internet Applications specification</h4>
		<p>Special thanks to Aaron Leventhal for effort and insight as he implemented a working prototype of accessibility <abbr title="Application Programming Interface">API</abbr> bindings. Special thanks to Al Gilman for his work while chair of the PFWG in bringing the ARIA technology to fruition.</p>
		<p> Jim Allan (TSB), Simon Bates, Chris Blouch (AOL), Judy Brewer (W3C/MIT),
		  Christian Cohrs, Donald Evans (AOL), Geoff Freed (WGBH/NCAM), Becky
		  Gibson (IBM), Alfred S. Gilman, Andres Gonzalez (Adobe), Jeff Grimes
		  (Oracle), Barbara Hartel, Earl Johnson (Sun), Jael Kurz, Aaron Leventhal
		  (IBM Corporation), Alex Li (SAP), Linda Mao (Microsoft), Shane McCarron
		  (ApTest), Lisa Pappas (Society for Technical Communication (STC)),
		  Dave Pawson (RNIB), David Poehlman, Marc Silbey (Microsoft Corporation),
		  Henri Sivonen (Mozilla), Vitaly Sourikov, Mike Squillace (IBM), Ryan Williams
		  (Oracle), Tom Wlodkowski.</p>
  </div>
	<div class="section" id="ack_funders">
		<h4><span class="tocnum">12.2.3. </span> Enabling funders</h4>
		<p>This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability and Rehabilitation Research (NIDRR) under contract number ED05CO0039. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.</p>
	</div>
</div>
</div>
</body></html>