- From: Léonie Watson <tink@tink.uk>
- Date: Mon, 11 Apr 2016 09:22:24 +0100
- To: "'Richard Schwerdtfeger'" <schwer@us.ibm.com>, "'Bo J Campbell'" <bcampbell@us.ibm.com>
- Cc: <janina@rednote.net>, <public-apa@w3.org>
- Message-ID: <024301d193cb$703ff960$50bfec20$@tink.uk>
From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] Sent: 10 April 2016 21:57 “This does not work either. The don't do's are a non-starter.” +1 “What they need to do is create a mapping spec. that exposes the information to the AT in an order that reflects the order provided. The text that should be exposed should be on the order of: The order in which the user agent exposes the elements to assistive technologies MUST reflect the order defined by the Flexbox used.” +1 “We agreed that tabindex would not be adjusted and that a better keyboard navigation mechanism should be investigated. I told the IBM product team that they need to limit the number of tab stops in order to minimize the brittleness of using tabindex. This is with the expectation that the actual order of the content exposed to ATs reflects the Flexbox order.” I’m not convinced tabindex could be amended to solve the problem, so strongly agree that it should be left out of the equation for FlexBox. “This would require the CSS working group to create a mapping specification for specific CSS features like Flexbox. It is highly unlikely that developers and designers will pay any attention to the do's and don'ts in the flexbox specification. If it looks the way they want then they will call it a day.” What about keyboard navigation outside of the accessibility APIs? The Firefox “bug” seems to be the best solution on the table at present [1]. Léonie. [1] http://tink.uk/flexbox-the-keyboard-navigation-disconnect/ -- @LeonieWatson tink.uk Carpe diem.
Received on Monday, 11 April 2016 08:26:14 UTC