WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: aria-disabled is really required

for

From: glen walker
Date: Mar 13, 2018 11:55AM

> The disabled attribute is only valid on certain HTML5 elements

> Another minor but sometimes important difference is that disabled removed
elements from the focus order automatically whereas aria-disabled doesn't.

Yes, I think I already said the same thing.

> both have a purpose

This just follows the simple first rule of aria
<https://www.w3.org/TR/using-aria/#rule1> use - use native html (eg, the
disabled property) if possible, then fall back to aria if necessary.

Saying aria-disabled and the disabled property both have a purpose is
analogous to saying that role=button and <button> both have a purpose,
which again goes back to the first rule.

Glen





On Tue, Mar 13, 2018 at 11:28 AM, Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> 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.
> > > > >