E-mail List Archives
Thread: Is a button that does not support space bar activation a violation of WCAG?
Number of posts in this thread: 17 (In chronological order)
From: Birkir R. Gunnarsson
Date: Wed, May 06 2015 1:37PM
Subject: Is a button that does not support space bar activation a violation of WCAG?
No previous message | Next message →
Hey guys
Frequently we see the following:
<code>
<a href="#" class="btn" role="button">I am a button now</a>
</code>
This is all right, except that it does not support activation using
the space bar key (only enter) ... except with screen readers that
automatically create that mapping for links and buttons, in my
testing.
I know this is not the accepted best practice, some users only use
space bar to execute buttons, sometimes using enter would accidentally
submit a form when user intended to activate a button in the form.
But is there a direct reference in WCAG or aa related W3C document
that buttons should always be coded so that they can be activated with
both enter and space bar?
(ARIA Authoring Practices is not normative(.
When dealing with large corporate clients this one additional
requirement can mean hundreds of developer hours, so the argument
needs to be as strong as possible,or this should be pointed out as a
best practice if it cannot be explicitly shown as a violation.
Cheers
-Birkir
--
Work hard. Have fun. Make history.
From: Steve Faulkner
Date: Wed, May 06 2015 3:10PM
Subject: Re: Is a button that does not support space bar activation a violation of WCAG?
← Previous message | Next message →
How does this one requirement involve 100's of extra hours developer time? It is simple in programming terms
Regards
Steve
> On 6 May 2015, at 21:37, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hey guys
>
> Frequently we see the following:
> <code>
> <a href="#" class="btn" role="button">I am a button now</a>
> </code>
> This is all right, except that it does not support activation using
> the space bar key (only enter) ... except with screen readers that
> automatically create that mapping for links and buttons, in my
> testing.
> I know this is not the accepted best practice, some users only use
> space bar to execute buttons, sometimes using enter would accidentally
> submit a form when user intended to activate a button in the form.
> But is there a direct reference in WCAG or aa related W3C document
> that buttons should always be coded so that they can be activated with
> both enter and space bar?
> (ARIA Authoring Practices is not normative(.
> When dealing with large corporate clients this one additional
> requirement can mean hundreds of developer hours, so the argument
> needs to be as strong as possible,or this should be pointed out as a
> best practice if it cannot be explicitly shown as a violation.
>
> Cheers
> -Birkir
>
>
> --
> Work hard. Have fun. Make history.
> > > >
From: Moore,Michael (DARS)
Date: Wed, May 06 2015 3:17PM
Subject: Re: Is a button that does not support space bar activationa violation of WCAG?
← Previous message | Next message →
Well first you draft the change request (CR) and submit it to IT for evaluation. From there it is passed to a business analyst to develop the business requirements (BRD) the BRD is passed to the contract manager who submits a request for proposal (RFP) to the implementation service provider who will respond with memorandum of understanding (MOU)...
Mike Moore
Accessibility Coordinator,
Texas Department of Assistive and Rehabilitative Services
(512) 424-4159 (Office)
(512) 574-0091 (Cell)
From: Steve Faulkner
Date: Wed, May 06 2015 4:08PM
Subject: Re: Is a button that does not support space bar activation a violation of WCAG?
← Previous message | Next message →
On 6 May 2015 at 22:17, Moore,Michael (DARS) < = EMAIL ADDRESS REMOVED =
> wrote:
> Well first you draft the change request (CR) and submit it to IT for
> evaluation. From there it is passed to a business analyst to develop the
> business requirements (BRD) the BRD is passed to the contract manager who
> submits a request for proposal (RFP) to the implementation service provider
> who will respond with memorandum of understanding (MOU)...
don't buy it,
--
Regards
SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>;
From: Birkir R. Gunnarsson
Date: Wed, May 06 2015 7:13PM
Subject: Re: Is a button that does not support space bar activation a violation of WCAG?
← Previous message | Next message →
Guys.
I was not asking whether it was hard or easy (I have a single
JavaScript function of 5 lines that adds the appropriate keyboard
interaction to all links turned buttons).
I was asking if it was an absolute requirement of WCAG that all
buttons be coded so that either enter or spacebar activates them.
My guess from where this discussion has gone is no.
Thanks
From: Jonathan Avila
Date: Wed, May 06 2015 7:22PM
Subject: Re: Is a button that does not support space bar activation a violation of WCAG?
← Previous message | Next message →
> I was asking if it was an absolute requirement of WCAG that all buttons be coded so that either enter or spacebar activates them. My guess from where this discussion has gone is no.
It depends who you talk too -- so -- at this point there is no consensus that I am aware of on this being a requirement. I'd assume we all agree it's at least advisory though. There are many other techniques that fall into this category and over time techniques may move from not having consensus into having consensus. For example, do banner and footer content have to be marked as such as with HTML5 or ARIA -- do groups of links have to be within a nav or use navigation role, etc. My thoughts are my own and I'm not speaking for any working groups.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Birkir R. Gunnarsson
Date: Wed, May 06 2015 7:37PM
Subject: Re: Is a button that does not support space bar activation a violation of WCAG?
← Previous message | Next message →
Yeah, that is the core of my question basically.
WCAG says that all page elements have to be keyboard operable, but the
standard does not specify a manner in which they have to be keyboard
operable.
I have always recommended space bar activation for buttons (because
that is a function supported by native html button elements).
It has never really come to a head for me, but I would have stopped
short of demanding it if buttons are made keyboard accessible in a
predictable or documented manner.
Cheers
On 5/6/15, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> I was asking if it was an absolute requirement of WCAG that all buttons be
>> coded so that either enter or spacebar activates them. My guess from
>> where this discussion has gone is no.
>
> It depends who you talk too -- so -- at this point there is no consensus
> that I am aware of on this being a requirement. I'd assume we all agree
> it's at least advisory though. There are many other techniques that fall
> into this category and over time techniques may move from not having
> consensus into having consensus. For example, do banner and footer content
> have to be marked as such as with HTML5 or ARIA -- do groups of links have
> to be within a nav or use navigation role, etc. My thoughts are my own and
> I'm not speaking for any working groups.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>
From: Paul J. Adam
Date: Wed, May 06 2015 7:45PM
Subject: Re: Is a button that does not support space bar activation a violation of WCAG?
← Previous message | Next message →
According to PCAG, Paul's Content Accessibility Guidelines, :) yes of course you must match the keyboard behavior to the role used on that element.
If you say role=button then you are saying "I work with the spacebar!" if you don't work with the space bar then you're just lying to the user and the Accessibility API ;)
I'm calling them WCAG failures if the keyboard interaction does not match the role. You can be flexible with complex ARIA menubar mega menu type widgets and allow both arrow navigation and tab key navigation through all elements so all users know how to work the control and power users can skip through it faster if desired.
Things I'd consider a fail would be using an ARIA role that implies spacebar, arrow key, or escape key behavior without actually implementing that behavior. Seems like a 4.1.2 failure, i.e. you are using the incorrect role for this element since the behavior does not match the standard native element.
Paul J. Adam
Accessibility Evangelist
www.deque.com <http://www.deque.com/>;
> On May 6, 2015, at 8:37 PM, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>
> Yeah, that is the core of my question basically.
> WCAG says that all page elements have to be keyboard operable, but the
> standard does not specify a manner in which they have to be keyboard
> operable.
> I have always recommended space bar activation for buttons (because
> that is a function supported by native html button elements).
> It has never really come to a head for me, but I would have stopped
> short of demanding it if buttons are made keyboard accessible in a
> predictable or documented manner.
> Cheers
>
>
>
>
>
> On 5/6/15, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>>> I was asking if it was an absolute requirement of WCAG that all buttons be
>>> coded so that either enter or spacebar activates them. My guess from
>>> where this discussion has gone is no.
>>
>> It depends who you talk too -- so -- at this point there is no consensus
>> that I am aware of on this being a requirement. I'd assume we all agree
>> it's at least advisory though. There are many other techniques that fall
>> into this category and over time techniques may move from not having
>> consensus into having consensus. For example, do banner and footer content
>> have to be marked as such as with HTML5 or ARIA -- do groups of links have
>> to be within a nav or use navigation role, etc. My thoughts are my own and
>> I'm not speaking for any working groups.
>>
>> Jonathan
>>
>> --
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group
>> = EMAIL ADDRESS REMOVED =
>>
>> 703-637-8957 (o)
>> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>>
>>
>>
From: Birkir R. Gunnarsson
Date: Wed, May 06 2015 7:52PM
Subject: Re: Is a button that does not support space bar activation a violation of WCAG?
← Previous message | Next message →
All good points.
The remaining experiment is to see if all html elements that map to
the button role
(button tag, input with type submit, reset, image, button ..
optionally the summary attribute though it is not well supported) can
be activated using the spacebar as well as the enter key.
If so,then we can definitely say that space bar activation of the
button role is firmly established, and an expected part of that role's
operation.
If anyone is wondering. I am preparing for my keyboard accessibility
testing class at Access U. Of course I encourage anyone going to
Access U to attend. ;)
Cheers
-B
On 5/6/15, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> According to PCAG, Paul's Content Accessibility Guidelines, :) yes of course
> you must match the keyboard behavior to the role used on that element.
>
> If you say role=button then you are saying "I work with the spacebar!" if
> you don't work with the space bar then you're just lying to the user and the
> Accessibility API ;)
>
> I'm calling them WCAG failures if the keyboard interaction does not match
> the role. You can be flexible with complex ARIA menubar mega menu type
> widgets and allow both arrow navigation and tab key navigation through all
> elements so all users know how to work the control and power users can skip
> through it faster if desired.
>
> Things I'd consider a fail would be using an ARIA role that implies
> spacebar, arrow key, or escape key behavior without actually implementing
> that behavior. Seems like a 4.1.2 failure, i.e. you are using the incorrect
> role for this element since the behavior does not match the standard native
> element.
>
> Paul J. Adam
> Accessibility Evangelist
> www.deque.com <http://www.deque.com/>;
>> On May 6, 2015, at 8:37 PM, Birkir R. Gunnarsson
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Yeah, that is the core of my question basically.
>> WCAG says that all page elements have to be keyboard operable, but the
>> standard does not specify a manner in which they have to be keyboard
>> operable.
>> I have always recommended space bar activation for buttons (because
>> that is a function supported by native html button elements).
>> It has never really come to a head for me, but I would have stopped
>> short of demanding it if buttons are made keyboard accessible in a
>> predictable or documented manner.
>> Cheers
>>
>>
>>
>>
>>
>> On 5/6/15, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>>>> I was asking if it was an absolute requirement of WCAG that all buttons
>>>> be
>>>> coded so that either enter or spacebar activates them. My guess from
>>>> where this discussion has gone is no.
>>>
>>> It depends who you talk too -- so -- at this point there is no consensus
>>> that I am aware of on this being a requirement. I'd assume we all agree
>>> it's at least advisory though. There are many other techniques that fall
>>> into this category and over time techniques may move from not having
>>> consensus into having consensus. For example, do banner and footer
>>> content
>>> have to be marked as such as with HTML5 or ARIA -- do groups of links
>>> have
>>> to be within a nav or use navigation role, etc. My thoughts are my own
>>> and
>>> I'm not speaking for any working groups.
>>>
>>> Jonathan
>>>
>>> --
>>> Jonathan Avila
>>> Chief Accessibility Officer
>>> SSB BART Group
>>> = EMAIL ADDRESS REMOVED =
>>>
>>> 703-637-8957 (o)
>>> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>>>
>>>
>>>
From: Sean Curtis
Date: Wed, May 06 2015 8:02PM
Subject: Re: Is a button that does not support space bar activation a violation of WCAG?
← Previous message | Next message →
http://jsbin.com/nofila/2/
Spacebar works on all of them (in Chrome/Safari/Firefox on OSX at least).
Spacebar also then causes a click event to bubble up.
If you're replicating native elements by using roles on something else, you
are responsible for ensuring those custom components behave the same way.
Cheers,
Sean
On Thu, May 7, 2015 at 11:52 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:
> All good points.
> The remaining experiment is to see if all html elements that map to
> the button role
> (button tag, input with type submit, reset, image, button ..
> optionally the summary attribute though it is not well supported) can
> be activated using the spacebar as well as the enter key.
> If so,then we can definitely say that space bar activation of the
> button role is firmly established, and an expected part of that role's
> operation.
> If anyone is wondering. I am preparing for my keyboard accessibility
> testing class at Access U. Of course I encourage anyone going to
> Access U to attend. ;)
> Cheers
> -B
>
>
> On 5/6/15, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
> > According to PCAG, Paul's Content Accessibility Guidelines, :) yes of
> course
> > you must match the keyboard behavior to the role used on that element.
> >
> > If you say role=button then you are saying "I work with the spacebar!" if
> > you don't work with the space bar then you're just lying to the user and
> the
> > Accessibility API ;)
> >
> > I'm calling them WCAG failures if the keyboard interaction does not match
> > the role. You can be flexible with complex ARIA menubar mega menu type
> > widgets and allow both arrow navigation and tab key navigation through
> all
> > elements so all users know how to work the control and power users can
> skip
> > through it faster if desired.
> >
> > Things I'd consider a fail would be using an ARIA role that implies
> > spacebar, arrow key, or escape key behavior without actually implementing
> > that behavior. Seems like a 4.1.2 failure, i.e. you are using the
> incorrect
> > role for this element since the behavior does not match the standard
> native
> > element.
> >
> > Paul J. Adam
> > Accessibility Evangelist
> > www.deque.com <http://www.deque.com/>;
> >> On May 6, 2015, at 8:37 PM, Birkir R. Gunnarsson
> >> < = EMAIL ADDRESS REMOVED = > wrote:
> >>
> >> Yeah, that is the core of my question basically.
> >> WCAG says that all page elements have to be keyboard operable, but the
> >> standard does not specify a manner in which they have to be keyboard
> >> operable.
> >> I have always recommended space bar activation for buttons (because
> >> that is a function supported by native html button elements).
> >> It has never really come to a head for me, but I would have stopped
> >> short of demanding it if buttons are made keyboard accessible in a
> >> predictable or documented manner.
> >> Cheers
> >>
> >>
> >>
> >>
> >>
> >> On 5/6/15, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> >>>> I was asking if it was an absolute requirement of WCAG that all
> buttons
> >>>> be
> >>>> coded so that either enter or spacebar activates them. My guess from
> >>>> where this discussion has gone is no.
> >>>
> >>> It depends who you talk too -- so -- at this point there is no
> consensus
> >>> that I am aware of on this being a requirement. I'd assume we all
> agree
> >>> it's at least advisory though. There are many other techniques that
> fall
> >>> into this category and over time techniques may move from not having
> >>> consensus into having consensus. For example, do banner and footer
> >>> content
> >>> have to be marked as such as with HTML5 or ARIA -- do groups of links
> >>> have
> >>> to be within a nav or use navigation role, etc. My thoughts are my own
> >>> and
> >>> I'm not speaking for any working groups.
> >>>
> >>> Jonathan
> >>>
> >>> --
> >>> Jonathan Avila
> >>> Chief Accessibility Officer
> >>> SSB BART Group
> >>> = EMAIL ADDRESS REMOVED =
> >>>
> >>> 703-637-8957 (o)
> >>> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
> >>>
> >>>
> >>>
From: Jonathan Avila
Date: Wed, May 06 2015 8:12PM
Subject: Re: Is a button that does not support space bar activationa violation of WCAG?
← Previous message | Next message →
> Things I'd consider a fail would be using an ARIA role that implies spacebar, arrow key, or escape key behavior without actually implementing that behavior. Seems like a 4.1.2 failure, i.e. you are using the incorrect role for this element since the behavior does not match the standard native element.
Then you might also say if something looks like a button but is implemented with a link then it's also a failure. These are all good discussions -- but we would really need consensus and then corresponding WCAG failure techniques to assist the wider community in determining conformance.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
From: Paul J. Adam
Date: Wed, May 06 2015 8:32PM
Subject: Re: Is a button that does not support space bar activationa violation of WCAG?
← Previous message | Next message →
I used to think and say that if it looked like a button visually then it should have role=button since most people would refer to it as a button in a conversation.
However, humans and designers all have very different opinions on what button or a link really looks like. On iOS now buttons look like blue links without an underline. Thanks to the flat design trends buttons don't really look like buttons any longer.
I'm also thinking that a screen reader user does not care what the UI element they're focused on looks like so it's best to set the role based on the functionality of the element rather than the look. Native mobile makes this more apparent. So elements that open external URLs should likely be a link role even if they look like a button and elements that function like expanding/collapsing widgets should likely be a button role rather than a link role even if they look like a typical link.
So eliminating the "if it looks like a" from the discussion makes determining the proper role much easier.
Paul J. Adam
Accessibility Evangelist
www.deque.com <http://www.deque.com/>;
> On May 6, 2015, at 9:12 PM, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Things I'd consider a fail would be using an ARIA role that implies spacebar, arrow key, or escape key behavior without actually implementing that behavior. Seems like a 4.1.2 failure, i.e. you are using the incorrect role for this element since the behavior does not match the standard native element.
>
> Then you might also say if something looks like a button but is implemented with a link then it's also a failure. These are all good discussions -- but we would really need consensus and then corresponding WCAG failure techniques to assist the wider community in determining conformance.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>
From: _mallory
Date: Wed, May 06 2015 9:50PM
Subject: Re: Is a button that does not support space bar activationa violation of WCAG?
← Previous message | Next message →
On Wed, May 06, 2015 at 09:32:20PM -0500, Paul J. Adam wrote:
> So eliminating the "if it looks like a" from the discussion makes determining the proper role much easier.
Only if one only cares about completely blind users.
I ran into a tab-panel while testing a page once. Wasted several
frustrated minutes of my life trying to figure out how to tab to
those suckers. The "tabs" looked like a bunch of normal page links,
but someone had marked them up as tab-panel I guess because clicking
once hid/showed content.
The screen reader tester was also flustered but that's because there's
no manual for non-developers on how to interact with tabs. She
discovered how they worked by accidentally hitting an arrow key, but
as she's totally blind that's a separate issue (users with zero
expectations simply because something is new rather than different
expectations based on how something looks).
Anyone who pulls that on me might or might not be breaking a WCAGgy
whatever but they totally deserver a bag of ants in their pants :P
_mallory
From: Paul J. Adam
Date: Wed, May 06 2015 9:57PM
Subject: Re: Is a button that does not support space bar activationa violation of WCAG?
← Previous message | Next message →
I think that tab control widgets can allow both arrow key navigation and regular TAB to each tab itself navigation. This way no one would be lost as to how to operate the control :)
Paul J. Adam
Accessibility Evangelist
www.deque.com <http://www.deque.com/>;
> On May 6, 2015, at 10:50 PM, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
>
> On Wed, May 06, 2015 at 09:32:20PM -0500, Paul J. Adam wrote:
>> So eliminating the "if it looks like a" from the discussion makes determining the proper role much easier.
>
> Only if one only cares about completely blind users.
>
> I ran into a tab-panel while testing a page once. Wasted several
> frustrated minutes of my life trying to figure out how to tab to
> those suckers. The "tabs" looked like a bunch of normal page links,
> but someone had marked them up as tab-panel I guess because clicking
> once hid/showed content.
> The screen reader tester was also flustered but that's because there's
> no manual for non-developers on how to interact with tabs. She
> discovered how they worked by accidentally hitting an arrow key, but
> as she's totally blind that's a separate issue (users with zero
> expectations simply because something is new rather than different
> expectations based on how something looks).
>
> Anyone who pulls that on me might or might not be breaking a WCAGgy
> whatever but they totally deserver a bag of ants in their pants :P
>
> _mallory
> > > >
From: _mallory
Date: Thu, May 07 2015 12:29AM
Subject: Re: Is a button that does not support space bar activationa violation of WCAG?
← Previous message | Next message →
On Wed, May 06, 2015 at 10:57:00PM -0500, Paul J. Adam wrote:
> I think that tab control widgets can allow both arrow key navigation and regular TAB to each tab itself navigation. This way no one would be lost as to how to operate the control :)
Really? I've been told by a number of people that tab has to go
into the tab list, next tab has to take you back out, unless you
open a tab, and then focus has to be moved into the panel (still
haven't figured a graceful way to do this part as our panels are
almost all text, so we've been tabindexing the panels and putting
focus in there, but that doesn't feel great either).
I mean tabs with role="tab" and "tabpanel" tabs.
We can also tab through tabs??
_mallory
From: Birkir R. Gunnarsson
Date: Thu, May 07 2015 6:47AM
Subject: Re: Is a button that does not support space bar activation a violation of WCAG?
← Previous message | Next message →
The tabpanel content should load when the tab becomes active, but I do
not think thefocus should move automatically to it . that would
actually break 3.2.1 (on focus) WCAG success criterion .. as a screen
reader user I want to explore the available tabs or move to the tab
tht is 3 arrow key presses to the right .. it would take me a heck of
a long time if every time I selected a different tab my focus was
grabbed and thrown to another part of the page).
I have recommended a two-way aria-controls (on tab) & aria-labelledby
(on tabpanel) relationship between tabs and tabpanels.
I have also recommended, as a best practice, to implement a key *such
as page down( that moves focus to the active tab panel from the active
tab.
Honestly we should leave that sort of functionality up to the
assistive technology, if we provide them with the relationships.
Jaws is the only screen reader, so far, that has taken advantage of
this .. pressing JawsKay Alt, M moves focus to controlled element
*target of aria-controls), only in FF.
I usually allow either tabs or arrows, I find it confusing, as a user,
to only allow arrows.
On 5/7/15, _mallory < = EMAIL ADDRESS REMOVED = > wrote:
> On Wed, May 06, 2015 at 10:57:00PM -0500, Paul J. Adam wrote:
>> I think that tab control widgets can allow both arrow key navigation and
>> regular TAB to each tab itself navigation. This way no one would be lost
>> as to how to operate the control :)
>
> Really? I've been told by a number of people that tab has to go
> into the tab list, next tab has to take you back out, unless you
> open a tab, and then focus has to be moved into the panel (still
> haven't figured a graceful way to do this part as our panels are
> almost all text, so we've been tabindexing the panels and putting
> focus in there, but that doesn't feel great either).
>
> I mean tabs with role="tab" and "tabpanel" tabs.
>
> We can also tab through tabs??
>
> _mallory
> > > > >
--
Work hard. Have fun. Make history.
From: _mallory
Date: Thu, May 07 2015 8:03AM
Subject: Re: Is a button that does not support space bar activation a violation of WCAG?
← Previous message | No next message
On Thu, May 07, 2015 at 08:47:52AM -0400, Birkir R. Gunnarsson wrote:
> I usually allow either tabs or arrows, I find it confusing, as a user,
> to only allow arrows.
As a user I've been "taught" by websites for over a decade that
I can Tab between "tabs", as they've never before ARIA been
anything other than links with CSS styling and some Javascript
woo to do the hide/show stuff.
But I can't go against the spec, even for usabiltiy.
_mallory