E-mail List Archives
Re: aria-disabled is really required
From: Birkir R. Gunnarsson
Date: Mar 13, 2018 11:28AM
- Next message: glen walker: "Re: aria-disabled is really required"
- Previous message: glen walker: "Re: aria-disabled is really required"
- Next message in Thread: glen walker: "Re: aria-disabled is really required"
- Previous message in Thread: glen walker: "Re: aria-disabled is really required"
- View all messages in this Thread
One thing is that aria-disabled works with elements repurposes with ARIA.
For instance:
This is valid
<div role="button" class="disabled" aria-disabled="true">Click me</div>
but this is not:
<div role="button" class="disabled" disabled>Click me</div>
The disabled attribute is only valid on certain HTML5 elements, not
generic elements repurposed with ARIA.
Another minor but sometimes important difference is that disabled
removed elements from the focus order automatically whereas
aria-disabled doesn't.
Sometimes it is better user experience to make them aware an element
is there but not abled, e.g. an input box or a button that is disabled
until user has made certain selections or filled in info.
Using the disabled attribute may hide this element from the user (it
is stll discoverable in browse mode, but much less obvious).
I can't think of an example right away, but there are situations where
I'd rather keep a disabled element focusable if there is a good reason
users need to know that the element is there.
So, both have a purpose, I like using the HTML5 disabled attribute
over ARIA, because it brings a lot of advantages and saves a lot of
JavaScript, but there are definitely strong enough arguments to keep
both around.
On 3/13/18, glen walker < <EMAIL REMOVED> > wrote:
>> So to clarify, setting â¬Åaria-disabled for element not supporting
> disabled is enough i.e. we don't have to do anything to the tabindex as
> screen readers indicate that they are disabled?
>
> Not exactly. Aria-disabled will cause the SR to say the element is
> disabled, but like all other ARIA attributes, it does *not* change
> behavior. If you have to set aria-disabled on a custom element, and that
> element is focusable because you have tabindex=0, then setting
> aria-disabled will not automatically remove that element from the tab
> order. You have to do it yourself because you have a custom element.
>
> For elements that natively support the disabled property (<input>,
> <button>, etc), then all that is taken care of for you.
>
> Same with the visuals of a disabled element. Native elements will
> automatically look different when disabled but setting aria-disabled on
> your custom element will not change its appearance. You'd need a class
> like:
>
> .myClass {
> /* normal styling */
> }
> .myClass[aria-disabled="true"] {
> /* stuff to make element look disabled */
> }
> > > > >
--
Work hard. Have fun. Make history.
- Next message: glen walker: "Re: aria-disabled is really required"
- Previous message: glen walker: "Re: aria-disabled is really required"
- Next message in Thread: glen walker: "Re: aria-disabled is really required"
- Previous message in Thread: glen walker: "Re: aria-disabled is really required"
- View all messages in this Thread