WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Auditing Calendars

for

From: Mohith BP
Date: Jan 14, 2018 5:37AM

Hi,

Please find the below check list prepared for the in-house auditing.
This may be of some help.

Calendar Requirements for Accessibility and Usability
Example – Accessible Calendars
Example 1:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm

Example 2:
https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker

Following is the requirement for the calendar from Accessibility Point of View:
1. The calendar field (edit box and the calendar icon need to be
focusable separately with tab and arrow key navigation.
2. User can either type the date in the specified format or choose
from the calendar.
3. On touch device: Tapping on the input field need to open the keypad
(preferably number keypad) and tapping on the calendar icon to open
the calendar widget to select the date.
4. The user should not be restricted to enter the date separator.
Currently if the user has specified dash (-) as date separator in the
settings one need to enter (-) only. The widget need to accept any
separator or input the separator automatically.
5. Calendar need to be accessible with screen readers with keyboard
and touch gestures.

Test Cases for Accessibility
Date edit field and Calendar icon
1. Both edit field and calendar icon need to be separately focusable
with tab key and arrow key navigation.
2. Date field need to have a clear label with the specific format
required to enter.
3. Calendar icon need to have the unique label. i.e., ‘Start Date
Calendar' to identify properly if there are more than one date field
in the page.
4. Date edit field need to accept the values from the user when typed.
5. Tapping on the text box need to open the keypad (numerical keypad)
on the touch devices.
6. There need not to be any restriction for entering the date separator
a. If the user types continuously, the separator will be entered
automatically based on the format specified.
b. Commonly used separators are allowed such as slash (/), dot (.),
dash (-), etc.
c. If the user enters the date separator without entering the whole
digits required for the specific group then the next entered value to
be considered in the next group. i.e., required format is MM/DD/YYYY
and the user enters 4-3-2018. This should be accepted as April 3,
2018.
When Calendar is Open
1. Activating calendar icon need to open the calendar and focus
today's date or the date displayed in the date edit box.
2. Next month, previous month and next year, previous year need to be
clearly labelled as below (current month is January 2018):
a. Previous Month December 2017.
b. Next Month February 2018.
c. Previous year 2017.
d. Next year 2019.
3. Next and previous month and next and previous year preferably need
to have role button. Link is also accepted.
4. The date displayed need to be in the HTML table. If the HTML table
tags cannot be used, please provide necessary aria grid roles.
5. Keyboard interactions:
a. Tab navigation will be restricted only to the calendar with both
tab and shift + tab navigation.
b. Tab focus will be provided to current date in focus, next month,
previous month, next year, previous year and close button.
c. Right Arrow: moves focus to the next date in the left-to-right
navigation. Does nothing if the focus is on the last date of the month
or optionally moves the focus to the first date of the next month.
d. Left Arrow: Moves the focus to the previous date in the
right-to-left fashion. Does nothing when the focus is on the first
date of the month or optionally moves to the last date of the previous
month.
e. Down Arrow: Moves the focus to the next week of the same day (in
the same column). Does nothing when the focus is on the last week of
the month.
f. Up Arrow: Moves the focus to the previous week of the same day (in
the same column). Does nothing when the focus is on the first week of
the month.
g. Page Up: Moves to the previous month of the same day.
h. Page Down: Moves to the next month of the same day.
i. Alt + Page Up: Moves to the previous year of the same date.
j. Alt + Page Down: Moves to the next year of the same date.
6. Activating any date with keyboard and tap, selects the date to the
text box and closes the calendar.
7. When calendar is closed, the focus returns to the date edit box. If
the focus returns to the Calendar icon, the calendar icon need to have
aria-describedby referring to the date currently selected in the date
edit box.
8. Calendar popup need to have a close button if the user wishes to
close the popup without selecting any date and the focus need to
brought back either to the date edit box or calendar icon. If there
are some visual restrictions for the close button, the close icon can
be hidden from the view till it gets the tab focus.

ARIA Best Practices
1. User interactions are restricted only to the calendar when calendar is open.
2. Calendar will have role as application.
3. The accessible name provided either through aria-label or
aria-labelledby will be in the following format in order to improve
the usability: "9, Tuesday January 2018"
4. There is no need to use aria-hidden property on the date displayed
as the aria-label or aria-labelledby will override the displayed text
from screen readers reading.
5. Preferably provide role = button to the date.
6. If HTML table tags are not used to structure the date, provide ARIA
grid roles as per the specifications.



Thanks & Regards,
Mohith B. P.


On 1/14/18, Peter Shikli < <EMAIL REMOVED> > wrote:
> We're familiar with general accessibility audit methodologies such as
> WCAG's <https://www.w3.org/TR/2014/NOTE-WCAG-EM-20140710/>, but I'm
> wondering if anyone has come across a methodology specific to auditing
> calendars, perhaps as a specialized variant or enhancement to one of the
> general methodologies?  Anything from a structured methodology,
> checklist, or even disorganized tips would be great to give our
> analysts.  I'm looking for something applicable to all calendar flavors
> from embedded commercial widgets to home-grown tables (with a dash of CSS).
>
> Cheers,
> Peter Shikli
> Access2online
> 503-570-6831 - <EMAIL REMOVED>
> www.access2online.com
> Prison inmates helping websites become accessible
> > > > >