- From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Date: Mon, 25 Apr 2016 15:44:25 +0000
- To: Birkir Gunnarsson <birkir.gunnarsson@deque.com>, "public-aria@w3.org" <public-aria@w3.org>
- Message-ID: <SN1PR0301MB1981C3D5ADB1286D61E7F0DE98620@SN1PR0301MB1981.namprd03.prod.outlook.>
One thing to keep in mind is that certain ARIA roles are meant to be composite widget containers, which support different child element roles as needed. http://www.w3.org/TR/2016/WD-wai-aria-1.1-20160317/#composite As such, like role=tablist, role=gridcell, etc., you can include supporting element structures accessibly if programmed correctly. An example of this is if you have a role=tablist container that includes a keyboard accessible Delete link associated with each role=tab element. To ensure correct reading order, these links would need to be included within the role=tablist container, however they cannot be included inside of the role=tab element because this is not a composite widget type. So the way this works accessibly, is that you can arrow between the role=tab elements, and as focus is set to each role=tab element, tabindex is also toggled on the associated Delete link so that you can simply press Tab from any role=tab element to set focus to Delete and activate it, and none of the others are in the tab order to prevent confusion. Also aria-describedby should be set on the Delete link to point to the ID of the associated role=tab element so that this is announced when it receives focus which also works on touch screen devices. For this to work though, you need to be able to add these Delete links inside of the role=tablist container as owned elements, even if they are not declared explicitly as such. The importance of this distinction also, is not to do this within widget roles that are not composite widgets, such as role=button, role=tab, role=treeitem, etc., because this will not work accessibly across devices if done this way. From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com] Sent: Sunday, April 24, 2016 1:19 PM To: public-aria@w3.org Subject: Lack of clarity regarding "required owned elements" All. I am working on an automated accessibility test for required owned elements of ARIA roles. The short version: Can an element own (or contain) elements with roles other than the required owned element role in addition to owning at least one instance of required role? e.g. - Can a tablist own tabpanels in addition to tabs? - Can a menu own a link or a span in addition to menuitem elements? My hnuch is no. If I look at the html equivalent, a <ul> tag can only own <li> tags, script tags or templates. If it owns a span, div or a button that fails validation. But I am not sure enough to write an automated check without further confirmation. ARIA spec Context: The required owned elements section (section 5.2.5 of http://www.w3.org/WAI/PF/aria-1.1/roles) states: "Any element that will be owned by the element with this role. For example, an element with the role list will own at least one element with the role group or listitem. When multiple roles are specified as required owned elements for a role, at least one instance of one required owned element is expected." Maybe it is confusion because English is not my native language, but does "any element" at the beginning of that sentence equate to "every element"? Thanks -Birkir
Received on Monday, 25 April 2016 15:44:58 UTC