- From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Date: Wed, 19 Nov 2014 19:16:10 +0000
- To: Matthew King <mattking@us.ibm.com>, "LWatson@PacielloGroup.com" <LWatson@PacielloGroup.com>
- CC: "public-pfwg@w3.org" <public-pfwg@w3.org>
- Message-ID: <BY2PR03MB34784B3E2FCE2139C1318DE98890@BY2PR03MB347.namprd03.prod.outlook.com>
Matt and others, So do you think there is a definitive need to have both aria-current and aria-selected remain separate in the Accessibility API? The reason why I ask, is that IE is leaning towards mapping both attributes to the same state (selected), which would make it impossible for ATs to detect the difference in the Accessibility Tree. From: Matthew King [mailto:mattking@us.ibm.com] Sent: Wednesday, November 19, 2014 9:42 AM To: LWatson@PacielloGroup.com Cc: public-pfwg@w3.org Subject: RE: ACTION-1442: Draft spec text for aria-current and aria-currentfor Léonie, I have applications that have a problem right now because we do not have both current and selected available. We need to indicate which page in a wiki tree is displayed. At the same time, We can also explore the tree and select a page for move or delete for when creating a sibling or child. The selection refers to the pages that are chosen for action, but they may not be the displayed page. I think this could be a farily common use case for having both in the same widget. With more words, we could certainly make the example more clear. But, rather than more words in the spec, I thought it may be better to direct people to the APG where we can have functional examples. Matt King IBM Senior Technical Staff Member I/T Chief Accessibility Strategist IBM BT/CIO - Global Workforce and Web Process Enablement Phone: (503) 578-2329, Tie line: 731-7398 mattking@us.ibm.com<mailto:mattking@us.ibm.com> From: Léonie Watson <LWatson@PacielloGroup.com<mailto:LWatson@PacielloGroup.com>> To: Matthew King/Fishkill/IBM@IBMUS, <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>, Date: 11/19/2014 09:34 AM Subject: RE: ACTION-1442: Draft spec text for aria-current and aria-currentfor ________________________________ Matt King wrote: “Note: When applied to an element contained in a widget that supports selection, the meaning of aria-current is different from the meaning of [aria-selected]. Authors should not use aria-current in lieu of aria-selected and should avoid using aria-current in circumstances where the meaning of aria-current would be the same as aria-selected. For example, in a single-select [tablist] where the selected [tab] element corresponds to the displayed tabpanel, aria-current is unnecessary. However, if the selected state of a tab is used to indicate which tab is selected for an action, such as move, delete, or make current, then aria-current should be used to indicate which tab represents the currently displayed tabpanel.” This still feels a bit confusing. I’m tempted to suggest that aria-current and aria-selected should never be used simultaneously on the same element. The UX for someone hearing that an element was both selected and current would be very confusing. Léonie. -- Senior Accessibility Engineer, TPG @LeonieWatson @PacielloGroup
Received on Wednesday, 19 November 2014 19:16:41 UTC