WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: accessible calendar controls

for

From: Bryan Garaventa
Date: Jan 27, 2022 2:21PM

Thank you, I'm glad it helps. 😊

I understand that as well, mainly because I am an experiential learner myself, and have learned more by doing over the years than I ever did from study alone. Comparitive analysis is also an extremely valuable technique for diagnosing various types of interactive widget designs, especially when something isn't quite right and it's difficult to pinpoint what the issue is. By comparing the assistive technology feedback and accessibility tree mappings between such widgets, it is often much easier to identify what may be missing or need tweaking to ensure the greatest level of accessibility by observing the attributes and focus management to identify what the differences are.

Plus there is always the option of simply downloading the archive and using it to implement accessible widgets out-of-the-box as well, , which anyone is welcome to do.

All the best,
Bryan


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
<EMAIL REMOVED>
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of <EMAIL REMOVED>
Sent: Thursday, January 27, 2022 11:35 AM
To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
Subject: Re: [WebAIM] accessible calendar controls

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Brian,
I agree that your site is very helpful.
I think repositories like this sometimes persuade reluctant developers to get on board. I recall two developers who told me a few years ago that they started learning about accessible Web techniques after I sent them links to some solutions.


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Geethavani.Shamanna
Sent: Thursday, January 27, 2022 5:27 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] accessible calendar controls

Thank you Bryan, this is very helpful.

Geetha
-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Bryan Garaventa via WebAIM-Forum
Sent: 26 January 2022 18:17
To: WebAIM Discussion List < <EMAIL REMOVED> >
Cc: Bryan Garaventa < <EMAIL REMOVED> >
Subject: Re: [WebAIM] accessible calendar controls

CAUTION: This mail comes from outside the University. Please consider this before opening attachments, clicking links, or acting on the content.

Hi,
There really isn't, mainly because there is no way to predict when or how a disabled element may be relevant. There are definitely bad UI designs where disabled elements are improperly used to represent controls that would be better served with toggles and the like, but these conditions have to be taken on a case by case basis.

To clarify, the word unavailable on Windows comes from the state that is set on the element in the accessibility tree when disabled, and isn't meant to convey that you can do something specific to make it enabled, though some UIs may make it possible to change something to cause the element to become enabled automatically.

You can see an example of this at
https://www.whatsock.com/Templates/Tooltips/Help%20(Responsive)/index.htm
Where the Submit button is disabled until you type the right answer in the edit field.

In this case, the disabled attribute is used on a standard button element, but it sets the same state as though aria-disabled were being used. If the ARIA attribute were used here instead, it would actually be incorrect because doing so would not disable the button, it would just be conveyed as being disabled without preventing the wrong data from being submitted.

Regarding the radio button example, often this is used correctly in circumstances where some conditions are true sometimes but not always. For example, if a specific number of shipping options are provided by a company, but depending on the product, only some of these are actually available at checkout, then the radios that are not applicable will be disabled.

I'm not sure if this answers your question, but hopefully it helps a bit.

All the best,
Bryan



Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
<EMAIL REMOVED>
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Geethavani.Shamanna
Sent: Wednesday, January 26, 2022 5:38 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] accessible calendar controls

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Hi Glen and all,

I recently tested a page where there were three radio buttons; one was selected by default, and the other two were disabled. The screen reader announced the labels of these radio buttons followed by 'unavailable'. It wasn't of course clear as to when those radio buttons would become available or what the user needed to do in order for them to turn into an enabled state.

With regard to disabled radio buttons, what is considered good practice? Should information about when they become available or what the user needs to do be included within the label?

Many thanks.
Geetha
-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen walker
Sent: 25 January 2022 21:23
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] accessible calendar controls

CAUTION: This mail comes from outside the University. Please consider this before opening attachments, clicking links, or acting on the content.

The whatsock example is a nice demo of unavailable days. You need to keep two things in mind if you're going to use aria-disabled. The first is that it's intended for interactive elements. Setting aria-disabled on plain text or a non-interactive element *should* still cause the screen reader to announce that it's disabled but it might be confusing if it's not an interactive element to begin with. In the case of choosing a date from a calendar, it seems appropriate to use.

Secondly, if you only use aria-disabled by itself with no other clarifying text, the screen reader might only announce that the element is "unavailable". Both JAWS and NVDA say "unavailable" when aria-disabled is true. VoiceOver on ios (and maybe on macos) will say "dimmed". Hearing "unavailable" or "dimmed" by itself might not convey enough information.
In the case of a calendar widget, hearing "unavailable" for a date actually makes sense. The date is not available. Hearing that a date is "dimmed"
might not make sense.

The whatsock example also has a title attribute on the button. The title will be used as the accessible description (which is generally announced after the accessible name) and has a value of "Disabled". For tech-savvy screen reader users, they will probably figure out that "unavailable" or "dimmed" combined with "Disabled" means they can't choose that date. You might want a more descriptive description, so to speak. Perhaps a title of "this date is not available". You have to balance between being desciptive enough and being succinct.