WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Should disabled elements receive tab focus

for

From: Birkir R. Gunnarsson
Date: Nov 1, 2016 10:09AM

I think it is good.
I would add something along the lines of:"Don't override focusable
behavior resulting from use of the html disabled attribute.
If it is necessary to keep a disabled lement in the focus order, use
aria-disabled="true" to indicate its disabled state to assistive
technologies, CSS to vidually indicate the disabled state of the
element, and Javascript to ensure that the element is truly disabled
for all users (mouse and keyboard).
-B


On 11/1/16, Ajay Sharma < <EMAIL REMOVED> > wrote:
> Hello, a sin sear thanks to all for sharing your views, this has
> certainly helped in understanding the impact of disabled elements in
> variety of scenarios.
>
> Also, recently came across few instances e.g. MS Office online, where
> tab focus goes on disabled elements such as undo, redo, copy paste
> etc, which are disabled by default in a new document, and same is the
> case with native desktop apps.
>
> So, came up with following conclusion,
>
> 1.Disabled interactive control should not be in tab order, except for
> some complex applications / scenarios, where it's certainn that
> keeping that particular element out of the tab order would confuse the
> AT user.
> 2.Disabling the submit button on the forms should be avoided to handle
> errors / validations.
> 3. In case of desktop apps, disabled elements should be focusable as
> here it's not as easy to navigate with reading keys as in web with
> browse mode.
>
> Please let me know if above assumptions are good enough to build an
> accessibility policy for a product.
>
> Best Regards,
> Ajay
>
> On 10/29/16, Mallory < <EMAIL REMOVED> > wrote:
>> " So the low vision user is forced to try and figure out what in the
>> form is needed to make that disabled control enabled so they can read it
>> only to find out it wasn't something they wanted anyway."
>>
>> This would be a case where designers, developers, info architects ought
>> to be coming up with better ways of getting necessary information to the
>> user. Or, if the necessary info is only in a faint disabled control,
>> that means something to fix.
>>
>> Though yeah, we often don't have the above luxury :)
>>
>>
>> On Fri, Oct 28, 2016, at 06:42 PM, Sailesh Panchang wrote:
>>> Designers / developers need to review when it makes sense to include
>>> disabled controls in the UI. For instance in the page navigation
>>> links, the 'Next' button can be disabled and yet be rendered visually
>>> when the last page is in view. It becomes conspicuous by being absent
>>> in the tab order then!
>>> On the other hand dependent controls generally should be hidden if
>>> they are disabled. It makes for a cleaner uncluttered UI for everyone.
>>> Please review
>>> http://www.mindoversight.com/csun/2016/Overview.html
>>> and example for poor design- disabled controls.
>>> Thanks,
>>> Sailesh
>>>
>>>
>>> On 10/28/16, Jonathan Avila < <EMAIL REMOVED> > wrote:
>>> >> So in the situation where there are two combo-boxes and a submit
>>> >> button
>>> >> on
>>> >> a page, and the second combo box has no choices until the first combo
>>> >> box
>>> >> has a selection made would you want that second combo to be in the tab
>>> >> order? We were talking about adding a aria-disabled to the second
>>> >> combo
>>> >> box until there are choices in the it, would make more sense to mark
>>> >> it
>>> >> completely disabled?
>>> >
>>> > I'd say it is best practice to advise the user that changing something
>>> > in a
>>> > control will affect/change or add content later/further in the
>>> > document.
>>> >
>>> > Jonathan
>>> >
>>> > Jonathan Avila
>>> > Chief Accessibility Officer
>>> > SSB BART Group
>>> > <EMAIL REMOVED>
>>> > 703.637.8957 (Office)
>>> >
>>> > Visit us online: Website | Twitter | Facebook | Linkedin | Blog
>>> > Check out our Digital Accessibility Webinars!
>>> >
>>> >
>>> >