E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: jeffgutsell
Date: Tue, Jan 25 2022 1:14PM
Subject: accessible calendar controls
No previous message | Next message →

I am looking for your feedback on distinguishing active and inactive days in a calendar widget.
I recently used walgreens.com to schedule a covid-19 test for someone. I was thrilled that most of the process was very accessible. The one widget that caused me some initial confusion was the calendar control.
The widget indicated the days when tests are available at my selected store by putting a link on the day. Days that were not providing tests just showed that number with no link I tried several times to pick a Friday test date before I noticed that day had no link.
I am presuming that using "aria-disabled" would be the way to distinguish the available days.

Meanwhile, I think I recall a discussion of calendar controls a few years ago but failed to find that in the archives just now.

Jeff Gutsell

From: Bryan Garaventa
Date: Tue, Jan 25 2022 1:57PM
Subject: Re: accessible calendar controls
← Previous message | Next message →

Hi,
You can see an example of using aria-disabled for specifying disabled date ranges at
http://whatsock.com/Templates/Datepickers/With%20Disabled%20Weekends/index.htm

All the best,
Bryan


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

From: glen walker
Date: Tue, Jan 25 2022 2:23PM
Subject: Re: accessible calendar controls
← Previous message | Next message →

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.

From: Geethavani.Shamanna
Date: Wed, Jan 26 2022 6:37AM
Subject: Re: accessible calendar controls
← Previous message | Next message →

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

From: Bryan Garaventa
Date: Wed, Jan 26 2022 11:16AM
Subject: Re: accessible calendar controls
← Previous message | Next message →

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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

From: glen walker
Date: Wed, Jan 26 2022 11:53AM
Subject: Re: accessible calendar controls
← Previous message | Next message →

To add to Bryan's wisdom, whether a user (sighted or not) can tell if an
element will become enabled based on other interactions is really a UX
issue. If it's not clear, then you'd need additional information on the
page. Whether that information is *required*, with respect to WCAG, is
debatable. From a UX perspective, I think it's needed. From a WCAG
perspective, you might argue that it fails either 2.4.6 because the labels
aren't descriptive enough or 3.3.2 because incomplete instructions are
given on how to use the interface. But whether it's required or not should
be irrelevant. You should do what's good for all users and make it clear.

From: Bryan Garaventa
Date: Wed, Jan 26 2022 12:55PM
Subject: Re: accessible calendar controls
← Previous message | Next message →

Wisdom ey, well thank you! 😊 If you mash your finger with a hammer enough times, you eventually learn something...


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

From: Geethavani.Shamanna
Date: Thu, Jan 27 2022 3:27AM
Subject: Re: accessible calendar controls
← Previous message | Next message →

Thank you Bryan, this is very helpful.

Geetha

From: jeffgutsell
Date: Thu, Jan 27 2022 12:35PM
Subject: Re: accessible calendar controls
← Previous message | Next message →

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.

From: Bryan Garaventa
Date: Thu, Jan 27 2022 2:21PM
Subject: Re: accessible calendar controls
← Previous message | No next message

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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com