WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: aria-disabled is really required

for

From: Mallory
Date: Mar 15, 2018 4:49AM

Birkir,
"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."

We ran into a crap situation with datepicker calendars marked up as grids. The aria 1.1 guides say "make all part focusable since Javascript is taking away native SR keyboarding, so that users can find all grids not just enabled ones" yet we had dates that needed to be unselectable (used aria-disabled). Since the 1.1 spec also mentions using aria-selected=true for the currently-focussed date I found it unsettling to have both aria-selected=true AND aria-disabled=true on the same element, so we used aria-selected for actually-selected dates and did nothing special with the focus.

It still didn't work great and I wish the 1.1 docs mentioned something about this kind of situation.

cheers,
Mallory

On Tue, Mar 13, 2018, at 6:55 PM, glen walker wrote:
> > 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.
> > > > > > > > > >
> > > >