29214 2015-10-20 16:54:26 +0000 Unclear why aria-hidden=true on focusable elements etc. should be ignored 2018-05-03 20:51:25 +0000 1 1 1 Unclassified ARIA Core AAM 1.1 PC Windows NT RESOLVED INVALID P2 normal --- 1 sailesh.panchang clown w3cbugzilla oldest_to_newest 123811 0 sailesh.panchang 2015-10-20 16:54:26 +0000 Reference: [WebAIM thread] aria-hidden for content outside modal dialog? - Oct 18/19, 2015 Steve wrote: "Element should not be exposed, unless it is focused or fires an accessibility event" is stated in mapping details for aria-hidden=true http://www.w3.org/TR/core-aam-1.1/#details-id-94 Comment: The above statement in the Mapping Rules appears to be opposite of what is stated in 5.1.2 "Including Elements in the Accessibility Tree." Nor is the rationale covered by the general mapping rules in 5.5.1. The cells in the table row for aria-hidden=true under 5.5 begin with "See Including Elements in the Accessibility Tree". ...which I believe is the normative 5.1.2. In practical terms, why should focusable elements within a container (like div or main with aria-hidden=true) be exposed to screen reader users if that is the intention of the aria-hidden rule above? They will be available to non screen reader users and if the intent is to make them available to SR users (SRs being the main AT with ARIA support), developers will need to programmatically ensure the focusable elements are out of the scope of aria-hidden=true. And if aria-hidden=true is to be ignored on a link that will be a problem. Consider a hack situation when this is suggested: When it is not possible to merge an image link and a text link with the same href placed next to each other, setting aria-hidden=true and tabindex=-1 on the image link puts it out of reach of keyboard and SR users. ===