- From: <chaals@yandex-team.ru>
- Date: Sun, 03 May 2015 11:54:02 +0200
- To: "lwatson@paciellogroup.com" <lwatson@paciellogroup.com>, 'Steve Faulkner' <faulkner.steve@gmail.com>, "'Schnabel, Stefan'" <stefan.schnabel@sap.com>
- Cc: 'Janina Sajka' <janina@rednote.net>, 'HTMLWG WG' <public-html@w3.org>, 'HTML Accessibility Task Force' <public-html-a11y@w3.org>, 'W3C WAI Protocols & Formats' <public-pfwg@w3.org>
I think it is well worth exploring what would break if we assumed that roles were generally meant to trigger behaviour that is defined by the browser, as appropriate for the user, rather than requiring every developer to add not only the role semantics but all the interaction, hoping they get it right… There are obvious exceptions - role="application" is explicitly meant to keep the browser *out* of interfering with the interaction. But pushing the burden of interaction design for relatively common components to each Web Developer is pretty backwards - it requires massive duplication of effort, whose opportunity cost is allowing developers to only focus on innovative new interaction patterns. And as the Web shows, it is a pretty fragile approach - even household name developers produce interfaces with serious accessibility problems, repeatedly over years. cheers 02.05.2015, 17:19, "Léonie Watson" <lwatson@paciellogroup.com>: > Another idea that has bubbled up from time to time, is the notion that the browser could provide basic functionality based on explicit roles. Keyboard interaction when role=”button” for example. > > It’s something that would have been good to have had from the outset, and it may be that too much existing content would break if we tried now. It’s worth exploring though perhaps? > > Léonie. > > -- > > Léonie Watson Senior accessibility engineer, TPG > > @LeonieWatson @PacielloGroup PacielloGroup.com -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Sunday, 3 May 2015 09:54:35 UTC