- From: Gez Lemon <glemon@paciellogroup.com>
- Date: Mon, 11 May 2015 15:00:00 +0100
- To: Léonie Watson <lwatson@paciellogroup.com>
- Cc: Steve Faulkner <faulkner.steve@gmail.com>, HTMLWG WG <public-html@w3.org>, Chaals from Yandex <chaals@yandex-team.ru>, Richard Schwerdtfeger <schwer@us.ibm.com>, Alice Boxhall <aboxhall@google.com>
On 11 May 2015 at 10:54, Léonie Watson <lwatson@paciellogroup.com> wrote: > From: Steve Faulkner [mailto:faulkner.steve@gmail.com] > Sent: 07 May 2015 06:42 <snipped> > 3. roles that match the default implicit semantics of interactive elements > [2] inherit the interaction behaviour of the native elements > > example: > > <div role=button>press me</div> > > can be activated the same way a html <button> element can be:. > > via space, enter ,click , touch or whatever. > > > This is where things start to get more complex. If we could get the browser > to throw in keyboard support for free, it might be a step in the right > direction though. > > > > With a custom button it’s necessary to provide both mouse and keyboard event > handlers/listeners. If you use a native <button>, the browser automatically > provides the keyboard support. > > > > What if the browser provided the equivalent keyboard behaviour based on the > presence of role=”button”, and the behaviour defined by the mouse handler? I think that's a good idea, as it will help with consistency. Sometimes we come across examples where developers haven't included keyboard support at all, and instances where they do they may not get it quite right (such as forgetting to cancel the browser's SCROLL event that's fired when SPACE is pressed on non-button elements). If this was all handled by the browser, not only does it make it easy for everyone it makes it consistent. Regards, Gez -- _____________________________ Senior Accessibility Consultant - TPG http://www.paciellogroup.com
Received on Monday, 11 May 2015 14:00:23 UTC