![\"Patrick](\"https:\/\/html5accessibility.com\/stuff\/wp-content\/uploads\/2022\/02\/IMG_8596-1.jpg\")
<\/p>\n<\/p>\n
aria-owns<\/code> is surprisingly strong magic<\/h2>\naria-owns<\/code> allows developers to restructure the parent-child relationships in the accessibility tree. This means that screen reader users may experience a different semantic structure and meaning to other users when they navigate and interact with content using their screen readers virtual\/browse mode<\/a>.<\/p>\nAccessibility Tree<\/strong><\/a><\/p>\nTree of accessible objects<\/a> that represents the structure of the user interface (UI<\/abbr>). Each node in the accessibility tree represents an element in the UI<\/abbr> as exposed through the accessibility API<\/abbr><\/a>; for example, a push button, a check box, or container.<\/p><\/blockquote>\nSimple example<\/h3>\n
Using aria-owns<\/code> to change meaning by swapping the order of words.<\/p>\nIn the DOM: Ass Backwards<\/h4>\n<p aria-owns=\"back ass\">\r\n<span id=\"ass\">Ass<\/span> \r\n<span id=\"back\">Backwards<\/span>\r\n<\/p>\r\n<\/pre>\nIn the Accessibility tree: Backwards Ass<\/h4>\nparagraph:Backwards Ass\r\n<\/pre>\nSome users get Ass Backwards <\/em>and others get Backwards Ass<\/strong><\/p>\nTry it for yourself<\/h4>\n
See the Pen
\nUntitled<\/a> by steve faulkner (@stevef<\/a>)
\non CodePen<\/a>.<\/p>\nown and owner<\/h3>\n
When you start doing more complex things with aria-owns<\/code>, things start getting hairy<\/em>. You may well have to add additional ARIA role<\/code> attributes to your base HTML to ensure robust structure.<\/p>\nIn the DOM: 3 single row tables<\/h4>\n
Table 1<\/strong> has the caption and column headers and aria-owns<\/code> referencing the id<\/code>‘s of the rows in tables 1, 2 and 3<\/p>\n<table aria-owns=\"r1 r2 r3\">\r\n<caption>Prices for lemons \r\nand pears in London<\/caption>\r\n<tr id=\"r1\">\r\n<td><\/td>\r\n<th>Lemons<\/th>\r\n<th>Pears<\/th>\r\n<\/tr>\r\n<\/table><\/pre>\nTable 2<\/strong> has a row with a row header and 2 data cells. Each has an explicit role<\/p>\n <table>\r\n<tr id=\"r2\" role=\"row\">\r\n<th role=\"rowheader\">Wholesale<\/th>\r\n<td role=\"cell\">\u00a31.00<\/td>\r\n<td role=\"cell\">\u00a31.50<\/td>\r\n<\/tr>\r\n<\/table><\/pre>\nTable 3<\/strong> has a row with a row header and 2 data cells. The roles are not explicitly identified, as their implicit roles identify them.<\/p>\n <table>\r\n<tr id=\"r3\">\r\n<th>Retail<\/th>\r\n<td>\u00a32.00<\/td>\r\n<td>\u00a32.50<\/td>\r\n<\/tr>\r\n<\/table><\/pre>\nIn the Accessibility tree: One, 3 row table, in Chrome at least<\/em><\/h4>\n![\"the](\"https:\/\/html5accessibility.com\/stuff\/wp-content\/uploads\/2022\/02\/chrometree.png\")
<\/p>\n
In the Firefox Accessibility tree: One, 2 row table, with text containers where the 3rd row should be<\/h4>\n
![\"In](\"https:\/\/html5accessibility.com\/stuff\/wp-content\/uploads\/2022\/02\/firefoxtree.png\")
<\/p>\n
Try it for yourself<\/h4>\n
See the Pen
\ntables owned<\/a> by steve faulkner (@stevef<\/a>)
\non CodePen<\/a>.<\/p>\nFocus on things falling apart<\/h3>\n
When focusable elements are manipulated using aria-owns<\/code> the going gets weird.<\/p>\nVirtual focus<\/h4>\n
Virtual focus order adheres to the accessibility tree representation, the links are in reverse order to the DOM.<\/p>\n
![\"NVDA](\"https:\/\/html5accessibility.com\/stuff\/wp-content\/uploads\/2022\/02\/linklist.png\")
<\/p>\n
TAB focus order becomes corrupted<\/h4>\n
Using the links test case<\/a> with a screen reader:<\/p>\n\n- Start with virtual focus on the heading.<\/li>\n
- Press the TAB key once, focus moves to the second link (expected)<\/li>\n
- Press the TAB key again, focus moves out of the page to the browser chrome control. The first link is not included in the TAB focus order.<\/li>\n<\/ol>\n
![\"Annotated](\"https:\/\/html5accessibility.com\/stuff\/wp-content\/uploads\/2022\/02\/focus.png\")
<\/p>\n
Try it for yourself<\/h4>\n
See the Pen
\nUntitled<\/a> by steve faulkner (@stevef<\/a>)
\non CodePen<\/a>.<\/p>\n