E-mail List Archives
Thread: Aria-disabled is required ?
Number of posts in this thread: 7 (In chronological order)
From: Kakarla Meharoon
Date: Thu, Mar 08 2018 6:26AM
Subject: Aria-disabled is required ?
No previous message | Next message →
… if we are correctly applying the HTML disabled attribute to these
elements, *do we actually need the aria-disabled attribute as well?*
If not, the where there are cases where we are NOT applying HTML disabled
when an element is disabled, shouldn't the fix be to do that, rather than
add aria-disabled?
See for example
https://stackoverflow.com/questions/38059140/when-to-use-the-disabled-attribute-vs-the-aria-disabled-attribute-for-html-eleme
which suggests that we don't need both.
From: Steve Faulkner
Date: Thu, Mar 08 2018 6:50AM
Subject: Re: Aria-disabled is required ?
← Previous message | Next message →
>
> … if we are correctly applying the HTML disabled attribute to these
> elements, *do we actually need the aria-disabled attribute as well?*
definitely not
Use the disabled attribute on any element that is allowed the disabled
> attribute
> <https://www.w3.org/TR/html/sec-forms.html#enabling-and-disabling-form-controls-the-disabled-attribute>
> in HTML5. Only use the aria-disabled attribute for elements that are *not
> allowed* to have a disabled attribute in HTML5
>
https://www.w3.org/TR/html-aria/#attr-disabled
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
On 8 March 2018 at 13:26, Kakarla Meharoon < = EMAIL ADDRESS REMOVED = >
wrote:
> … if we are correctly applying the HTML disabled attribute to these
> elements, *do we actually need the aria-disabled attribute as well?*
>
> If not, the where there are cases where we are NOT applying HTML disabled
> when an element is disabled, shouldn't the fix be to do that, rather than
> add aria-disabled?
>
> See for example
> https://stackoverflow.com/questions/38059140/when-to-
> use-the-disabled-attribute-vs-the-aria-disabled-attribute-for-html-eleme
> which suggests that we don't need both.
> > > > >
From: Kakarla Meharoon
Date: Thu, Mar 08 2018 10:02AM
Subject: Re: aria-disabled is really required
← Previous message | Next message →
if we are correctly applying the HTML disabled attribute to these elements,
*do we actually need the aria-disabled attribute as well?*
If not, the where there are cases where we are NOT applying HTML disabled
when an element is disabled, shouldn't the fix be to do that, rather than
add aria-disabled?
See for example https://stackoverflow.com/questions/38059140/when-to-
use-the-disabled-attribute-vs-the-aria-disabled-attribute-for-html-eleme which
suggests that we don't need both.
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?
So basically the issue is mostly with elements that are styled to look
disabled.
*With best regards,*
*K.S.Meharoon*
*9700120786*
From: glen walker
Date: Tue, Mar 13 2018 11:15AM
Subject: Re: aria-disabled is really required
← Previous message | Next message →
> 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 */
}
From: Birkir R. Gunnarsson
Date: Tue, Mar 13 2018 11:28AM
Subject: Re: aria-disabled is really required
← Previous message | Next message →
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 ADDRESS 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.
From: glen walker
Date: Tue, Mar 13 2018 11:55AM
Subject: Re: aria-disabled is really required
← Previous message | Next message →
> 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 ADDRESS 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 ADDRESS 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.
> > > > >
From: Mallory
Date: Thu, Mar 15 2018 4:49AM
Subject: Re: aria-disabled is really required
← Previous message | No next message
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 ADDRESS 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 ADDRESS 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.
> > > > > > > > > >
> > > >