E-mail List Archives

Search E-mail List Archives for

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

From: Peter Shikli
Date: Sat, Jan 13 2018 2:28PM
Subject: Auditing Calendars
No previous message | Next message →

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 ADDRESS REMOVED =
www.access2online.com
Prison inmates helping websites become accessible

From: Jennifer Sutton
Date: Sat, Jan 13 2018 4:52PM
Subject: Re: Auditing Calendars
← Previous message | Next message →

Hello:


Before I answer your question, let me say that I like this notion of
having prisoners help assess websites for accessibility. I prefer assess
to "audit;" it's less scary, despite how much the current legal climate
in the U.S. feels like "auditing" is the thing to be doing.


At any rate, to assess, these days, it's essential that folks know
Javascript, ARIA, and preferably, even some frameworks, so I hope you'll
be able to collaborate with some of the companies in the industry in
order to assure prisoners are getting the training they need, beyond CSS
and HTML. I can't imagine how you could have an online calendar made
from only CSS and HTML, unless it's a read-only calendar, rather than an
interactive one.


That's not to minimize the importance of CSS and HTML; it's only to say
that more and more, assessments require the need to assess web
application-like products, rather than what I think of as more static sites.


This topic of calendars has been discussed many times on the list, so
I'll provide some links to threads that have been within the last year
or so, below.


I hope this helps you, those with whom you work, and others in our
industry who may be willing to offer services to support both people
with disabilities and prisoners who are assisting us. This is one of the
best things I've seen in our industry in a long time; it's like
prisoners who help with braille transcription. Keep up the good work,
and I, for one, appreciate this approach -- a way to help prisoners gain
marketable skills, even beyond accessibility testing (which can be
rather a niche/limiting), while helping others.


Best,

Jennifer


A thread from February of 2017:

https://webaim.org/discussion/mail_thread?thready70


A thread from Oct. 2016:

https://webaim.org/discussion/mail_thread?threadw35


Although it may be cited in either or both of the threads, above, here's
a collection of date-pickers that may be helpful:

http://www.webaxe.org/accessible-date-pickers/


If folks have additions to Dennis's compilation, if you post in the
comments, I'm sure he'll consider them.


As far as I know, one of the best things to do is to refer to Bryan's
AccDC Style guide to understand what a calendar/date-picker must
contain. Start here:
https://github.com/accdc/tsg

And here's this last, from Bryan, as a bonus:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(with%20Disabled%20Date%20Ranges)/demo.htm

On 1/13/2018 1:28 PM, Peter Shikli 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 ADDRESS REMOVED =
> www.access2online.com
> Prison inmates helping websites become accessible
> > > > ---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

From: Mohith BP
Date: Sun, Jan 14 2018 5:37AM
Subject: Re: Auditing Calendars
← Previous message | No next message

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 ADDRESS 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 ADDRESS REMOVED =
> www.access2online.com
> Prison inmates helping websites become accessible
> > > > >