Proposal to expose calendar view information to screen readers

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to expose calendar view information to screen readers

Marco Zehe-3
Hi there!

At
https://wiki.mozilla.org/Accessibility/CalendarExposure,
I've started a proposal to expose calendar view information such as the
one in the Lightning extension for Thunderbird, to assistive
technologies such as screen readers.

Since there is not much to go on in terms of previous implementations,
we're basically free to set the standard here, or as some would say who
have fought calendaring apps in the past, to finally set *a* standard.

It is hoped that this proposal, once formulated out and implemented in
Lightning, will also become part of other web-based calendars such as
Google Calendar.

I therefore encourage everyone interested or involved to take a look and
add to the page as I will most probably not have covered all features.
Being blind myself, there is a very good chance I'm missing out on a lot
of information.

Thanks!
Marco
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to expose calendar view information to screen readers

Aaron Leventhal-3
Marco,

What's an "item" that aria-calstatus, etc. would go on?

- Aaron

On 1/7/2009 8:02 AM, Marco Zehe wrote:

> Hi there!
>
> At
> https://wiki.mozilla.org/Accessibility/CalendarExposure,
> I've started a proposal to expose calendar view information such as the
> one in the Lightning extension for Thunderbird, to assistive
> technologies such as screen readers.
>
> Since there is not much to go on in terms of previous implementations,
> we're basically free to set the standard here, or as some would say who
> have fought calendaring apps in the past, to finally set *a* standard.
>
> It is hoped that this proposal, once formulated out and implemented in
> Lightning, will also become part of other web-based calendars such as
> Google Calendar.
>
> I therefore encourage everyone interested or involved to take a look and
> add to the page as I will most probably not have covered all features.
> Being blind myself, there is a very good chance I'm missing out on a lot
> of information.
>
> Thanks!
> Marco

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to expose calendar view information to screen readers

Marco Zehe-3
Hi Aaron,

On 07.01.2009 09:52, Aaron Leventhal wrote:
> What's an "item" that aria-calstatus, etc. would go on?

An item within a day or month view. For example: If you have an all-day
appointment set for the 8th of January, and you navigate to that day in
the day view, the individual time slots would get that state set to
"busy" or "booked", or whatever we agree upon.

Likewise, in the month view, the item for that particular day would get
this status set to indicate that there is something going on on that day.

Marco
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to expose calendar view information to screen readers

Aaron Leventhal-3
What role do those items have?

I suggest we do this with ARIA extensibility, to lead the way to making
official extensions.

http://wiki.mozilla.org/Accessibility/JSON_ARIA
This means you need to write up the JSON description of each new role,
what they inherit from, and what new properties they support.

For example, a role of "calday" could inherit from "cell". By doing this
we can get started on a compelling example of how custom widgets will be
developed. It's a longer route than just throwing in new properties, but
much better in the long run.

- Aaron


On 1/7/2009 10:09 AM, Marco Zehe wrote:

> Hi Aaron,
>
> On 07.01.2009 09:52, Aaron Leventhal wrote:
>> What's an "item" that aria-calstatus, etc. would go on?
>
> An item within a day or month view. For example: If you have an all-day
> appointment set for the 8th of January, and you navigate to that day in
> the day view, the individual time slots would get that state set to
> "busy" or "booked", or whatever we agree upon.
>
> Likewise, in the month view, the item for that particular day would get
> this status set to indicate that there is something going on on that day.
>
> Marco

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to expose calendar view information to screen readers

Marco Zehe-3
Hi Aaron,

Are the infrastructural things in place to digest such JSON files? In
other words, do we do something with this yet in Firefox if we see it,
like turning properties into object attributes?

The problem is that the Calendar needs to be at least partially
accessible for Thunderbird 3.0/Lightning 1.0, which will be based on
Gecko 1.9.1. If we need to make changes to turn such JSON properties
into object attributes, there is no way we can make this happen for
Gecko 1.9.1 AFAICS.

In principle, I agree that this would be a great example for role
extensibility via JSON, since these will be things like gridcell, grid
etc. ARIA roles augmented with custom attributes.

Marco

On 07.01.2009 11:03, Aaron Leventhal wrote:

> What role do those items have?
>
> I suggest we do this with ARIA extensibility, to lead the way to making
> official extensions.
>
> http://wiki.mozilla.org/Accessibility/JSON_ARIA
> This means you need to write up the JSON description of each new role,
> what they inherit from, and what new properties they support.
>
> For example, a role of "calday" could inherit from "cell". By doing this
> we can get started on a compelling example of how custom widgets will be
> developed. It's a longer route than just throwing in new properties, but
> much better in the long run.
>
> - Aaron
>
>
> On 1/7/2009 10:09 AM, Marco Zehe wrote:
>> Hi Aaron,
>>
>> On 07.01.2009 09:52, Aaron Leventhal wrote:
>>> What's an "item" that aria-calstatus, etc. would go on?
>>
>> An item within a day or month view. For example: If you have an all-day
>> appointment set for the 8th of January, and you navigate to that day in
>> the day view, the individual time slots would get that state set to
>> "busy" or "booked", or whatever we agree upon.
>>
>> Likewise, in the month view, the item for that particular day would get
>> this status set to indicate that there is something going on on that day.
>>
>> Marco
>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to expose calendar view information to screen readers

Aaron Leventhal-3
Marco, at this point your attributes will be exposed, but the info in
the JSON won't be.

We can take a two-pronged approach -- short and long term access goals.
For access in Tbird 3 and Lightning 1 we can just hard code the meaning
of those things into the AT. However, we should still do the JSON file.
This is our chance to think things through and start on the long term
journey.

- Aaron

On 1/7/2009 11:29 AM, Marco Zehe wrote:

> Hi Aaron,
>
> Are the infrastructural things in place to digest such JSON files? In
> other words, do we do something with this yet in Firefox if we see it,
> like turning properties into object attributes?
>
> The problem is that the Calendar needs to be at least partially
> accessible for Thunderbird 3.0/Lightning 1.0, which will be based on
> Gecko 1.9.1. If we need to make changes to turn such JSON properties
> into object attributes, there is no way we can make this happen for
> Gecko 1.9.1 AFAICS.
>
> In principle, I agree that this would be a great example for role
> extensibility via JSON, since these will be things like gridcell, grid
> etc. ARIA roles augmented with custom attributes.
>
> Marco
>
> On 07.01.2009 11:03, Aaron Leventhal wrote:
>> What role do those items have?
>>
>> I suggest we do this with ARIA extensibility, to lead the way to making
>> official extensions.
>>
>> http://wiki.mozilla.org/Accessibility/JSON_ARIA
>> This means you need to write up the JSON description of each new role,
>> what they inherit from, and what new properties they support.
>>
>> For example, a role of "calday" could inherit from "cell". By doing this
>> we can get started on a compelling example of how custom widgets will be
>> developed. It's a longer route than just throwing in new properties, but
>> much better in the long run.
>>
>> - Aaron
>>
>>
>> On 1/7/2009 10:09 AM, Marco Zehe wrote:
>>> Hi Aaron,
>>>
>>> On 07.01.2009 09:52, Aaron Leventhal wrote:
>>>> What's an "item" that aria-calstatus, etc. would go on?
>>>
>>> An item within a day or month view. For example: If you have an all-day
>>> appointment set for the 8th of January, and you navigate to that day in
>>> the day view, the individual time slots would get that state set to
>>> "busy" or "booked", or whatever we agree upon.
>>>
>>> Likewise, in the month view, the item for that particular day would get
>>> this status set to indicate that there is something going on on that
>>> day.
>>>
>>> Marco
>>
>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to expose calendar view information to screen readers

Willie Walker
In reply to this post by Marco Zehe-3
Thanks Marco!

Just a couple quick comments...keep in mind I didn't read your page in
great detail:

1) Evolution's Calendar is kind of sort of OK for accessibility on Linux.

2) I think a calendar can be viewed as kind of a new meta-widget that
comprises many widgets that already have roles that are well known to
screen readers.  It would be great if the implementation of Lightening
continued down this path so screen readers need not have a priori
knowledge of any new calendar roles.  That is, screen readers should
hopefully be able to provide some level of decent calendar access
without knowledge of the new calendar roles, but then provide stellar
access if they do know about the calendar roles.

Thanks for your work on this!

Will

Marco Zehe wrote:

> Hi there!
>
> At
> https://wiki.mozilla.org/Accessibility/CalendarExposure,
> I've started a proposal to expose calendar view information such as the
> one in the Lightning extension for Thunderbird, to assistive
> technologies such as screen readers.
>
> Since there is not much to go on in terms of previous implementations,
> we're basically free to set the standard here, or as some would say who
> have fought calendaring apps in the past, to finally set *a* standard.
>
> It is hoped that this proposal, once formulated out and implemented in
> Lightning, will also become part of other web-based calendars such as
> Google Calendar.
>
> I therefore encourage everyone interested or involved to take a look and
> add to the page as I will most probably not have covered all features.
> Being blind myself, there is a very good chance I'm missing out on a lot
> of information.
>
> Thanks!
> Marco
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to expose calendar view information to screen readers

Loretta Guarino Reid
In reply to this post by Marco Zehe-3
HI, Marco,

I looked at your specification, and I have some questions about exposing the
items in the calendar.

Since calendar events may only fill part of a slot, should there be a status
between free and booked? Partially booked?

Since Google Calendar can displays events from several calendars at once, do
we need an attribute for identifying the calendar that the event came from?
Are there other attributes of an event that should be exposed, such as
whether or not the event has been accepted or declined?

Is it possible to select events, or only cells? If an event spans several
cells, are they all selected? If you navigate between those cells, is the
event repeated each time?

Is there a way to navigate between events, rather than calendar slots? The
proposed API seems very much oriented towards navigating calendar slots.

Thanks, Loretta

On Tue, Jan 6, 2009 at 11:02 PM, Marco Zehe <[hidden email]> wrote:

> Hi there!
>
> At
> https://wiki.mozilla.org/Accessibility/CalendarExposure,
> I've started a proposal to expose calendar view information such as the one
> in the Lightning extension for Thunderbird, to assistive technologies such
> as screen readers.
>
> Since there is not much to go on in terms of previous implementations,
> we're basically free to set the standard here, or as some would say who have
> fought calendaring apps in the past, to finally set *a* standard.
>
> It is hoped that this proposal, once formulated out and implemented in
> Lightning, will also become part of other web-based calendars such as Google
> Calendar.
>
> I therefore encourage everyone interested or involved to take a look and
> add to the page as I will most probably not have covered all features. Being
> blind myself, there is a very good chance I'm missing out on a lot of
> information.
>
> Thanks!
> Marco
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to expose calendar view information to screen readers

Marco Zehe-3
In reply to this post by Marco Zehe-3
Hi Loretta!

On 13.01.2009 03:32, Loretta Guarino Reid wrote:
> Since calendar events may only fill part of a slot, should there be a status
> between free and booked? Partially booked?
That's something I stumbled upon also when writing up a more formalized
version of my proposal which hasn't been posted to the Wiki yet. One
solution I came up with is to include the end date and time in the
attributes so ATS don't have to go look somewhere else, but can deduce
the start date and time from the current slot. Adding status of
"partially booked" is a great idea!

> Since Google Calendar can displays events from several calendars at once, do
> we need an attribute for identifying the calendar that the event came from?
Thanks for this, I had forgotten that this is possible. So I'd say a
definitive yes on this question.

> Are there other attributes of an event that should be exposed, such as
> whether or not the event has been accepted or declined?
I'm still collecting ideas, and I believe this is also useful data to
expose. If ATS then use it is up to them.

>
> Is it possible to select events, or only cells? If an event spans several
> cells, are they all selected? If you navigate between those cells, is the
> event repeated each time?
Again, there is no standard to go from yet, we're basically attempting
to create a useful model here. Does Google Calendar offer keyboard
navigation by events or by cells in the calendar view? The desktop
calendars I now offer a sort of event list that is linked to the
currently selected date (or contains, like in Lightning, the events of
the next seven days) in a plain list view.
So to better get an idea of what's needed, can you comment on what
keyboard nav Google Calendar currently offers?

> Is there a way to navigate between events, rather than calendar slots? The
> proposed API seems very much oriented towards navigating calendar slots.

Again, this isn't the final, it's a first proposal and can be defined.
At this stage, we can easily add event types for API exposure.

Thanks, this is exactly the kind of feedback I was hoping to get!

Marco
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to expose calendar view information to screen readers

Marco Zehe-3
In reply to this post by Marco Zehe-3
Hi Willie,

On 08.01.2009 17:20, Willie Walker wrote:
> 1) Evolution's Calendar is kind of sort of OK for accessibility on Linux.
Well...We want to get away from the "kind of sort of" aspect of this if
possible. The Outlook Calendar on Windows is also "kind of sort of"
accessible, but it requires a lot of scripting and/or internal coding to
get some versions of Outlook accessible, kinda sorta... :-)
What I am hoping to kick off is a proposal that different vendors will
pick up, regardless of whether their calendar app runs in the browser,
as a XUL application or any other kind of environment. The goal is to
make this a showcase for role extensibility in ARIA, giving screen
readers and other assistive technologies the power to learn about each
calendar's implementation using a JSON file and therefore offer the best
possible user experience with the least amount of work for individual
calendaring apps.

> 2) I think a calendar can be viewed as kind of a new meta-widget that
> comprises many widgets that already have roles that are well known to
> screen readers. It would be great if the implementation of Lightening
> continued down this path so screen readers need not have a priori
> knowledge of any new calendar roles. That is, screen readers should
> hopefully be able to provide some level of decent calendar access
> without knowledge of the new calendar roles, but then provide stellar
> access if they do know about the calendar roles.
That's the general idea. Provide basic access, but use role
extensibility to get the best access possible.

Marco


_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility