E-mail List Archives

Search E-mail List Archives for

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

From: mhysnm1964
Date: Fri, Jun 22 2018 12:26AM
Subject: Navigation in application mode
No previous message | Next message →

Hi all.

I have a dev who is doing something really non-standard. As far as I
understand the issue at this point of time. He wants to use the up/down
arrow to move between meetings. The left and right arrow moving between the
days. Using non-application mode will not work due to screen readers as far
as I can tell. But he wants use the application role to achieve this. These
UI I am referring to have buttons for next and prior day. The meetings from
memory are not in any UI element like a list.

Any ideas how this can be achieved without using application mode?


How does the javascript keyboard event handle keyboard navigation when it is
not on an element. Do you have to apply the keyboard event to the body of
the html and track from there?

Sean

From: Tim Harshbarger
Date: Fri, Jun 22 2018 7:23AM
Subject: Re: [EXTERNAL] Navigation in application mode
← Previous message | Next message →

Instead of using role="application", it would be better to use an ARIA design pattern that more closely matched the interaction.

The thing with role="application" is that, while it puts screen reader users in forms mode, it doesn't really tell us how to get around the application. So using role="application" for one part of the page is not likely to inform screen reader users that pressing the up and down arrow keys will move from meeting to meeting and pressing the left and right arrow keys will move between days.

A listbox might work because a screen reader user will expect the up and down arrow keys to move up and down the list. Unfortunately, there is also an expectation that using the left and right arrow keys will do the same exact thing as using the up and down arrow keys. Users would not expect the left and right arrow keys to move between days. If you used a listbox, you likely would need to explicitly inform users of what the left and right arrow keys do differently.

To me, this sounds more like a grid. In a grid, there would likely be a better expectation that the up and down arrow keys would move within the day while the left and right arrow keys move between days.

Thanks,
Tim

From: Brandon Keith Biggs
Date: Fri, Jun 22 2018 9:38AM
Subject: Re: [EXTERNAL] Navigation in application mode
← Previous message | Next message →

Hello,
Here is a good design for a calendar:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm

If you want to add in appointments, tell the user how many appointments
there are each day and allow them to hit enter to see what is on that day
and escape to exit back to the date picker.
Thanks,

Brandon Keith Biggs <http://brandonkeithbiggs.com/>;


On Fri, Jun 22, 2018 at 6:23 AM Tim Harshbarger <
= EMAIL ADDRESS REMOVED = > wrote:

> Instead of using role="application", it would be better to use an ARIA
> design pattern that more closely matched the interaction.
>
> The thing with role="application" is that, while it puts screen reader
> users in forms mode, it doesn't really tell us how to get around the
> application. So using role="application" for one part of the page is not
> likely to inform screen reader users that pressing the up and down arrow
> keys will move from meeting to meeting and pressing the left and right
> arrow keys will move between days.
>
> A listbox might work because a screen reader user will expect the up and
> down arrow keys to move up and down the list. Unfortunately, there is also
> an expectation that using the left and right arrow keys will do the same
> exact thing as using the up and down arrow keys. Users would not expect
> the left and right arrow keys to move between days. If you used a listbox,
> you likely would need to explicitly inform users of what the left and right
> arrow keys do differently.
>
> To me, this sounds more like a grid. In a grid, there would likely be a
> better expectation that the up and down arrow keys would move within the
> day while the left and right arrow keys move between days.
>
> Thanks,
> Tim
>
>
>

From: Birkir R. Gunnarsson
Date: Fri, Jun 22 2018 11:50AM
Subject: Re: [EXTERNAL] Navigation in application mode
← Previous message | Next message →

I would go with a grid
http://www.w3.org/TR/wai-aria-practices-1.1/#grid
Once inside a grid the screen reader should automatically switch to
application/forms mode passing keys through to the webpage.
Then you can set up keyboard listeners to respond to the arrow key presses.
For the JQuery script see this example of an accessible date picker:
https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker
I workd with a developer to create this. As it was done in 2014 when
the grid role was poorly supported we used role="application" to force
the application mode, I believe that is no longer necessary.



On 6/22/18, Brandon Keith Biggs < = EMAIL ADDRESS REMOVED = > wrote:
> Hello,
> Here is a good design for a calendar:
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm
>
> If you want to add in appointments, tell the user how many appointments
> there are each day and allow them to hit enter to see what is on that day
> and escape to exit back to the date picker.
> Thanks,
>
> Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
>
>
> On Fri, Jun 22, 2018 at 6:23 AM Tim Harshbarger <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Instead of using role="application", it would be better to use an ARIA
>> design pattern that more closely matched the interaction.
>>
>> The thing with role="application" is that, while it puts screen reader
>> users in forms mode, it doesn't really tell us how to get around the
>> application. So using role="application" for one part of the page is not
>> likely to inform screen reader users that pressing the up and down arrow
>> keys will move from meeting to meeting and pressing the left and right
>> arrow keys will move between days.
>>
>> A listbox might work because a screen reader user will expect the up and
>> down arrow keys to move up and down the list. Unfortunately, there is
>> also
>> an expectation that using the left and right arrow keys will do the same
>> exact thing as using the up and down arrow keys. Users would not expect
>> the left and right arrow keys to move between days. If you used a
>> listbox,
>> you likely would need to explicitly inform users of what the left and
>> right
>> arrow keys do differently.
>>
>> To me, this sounds more like a grid. In a grid, there would likely be a
>> better expectation that the up and down arrow keys would move within the
>> day while the left and right arrow keys move between days.
>>
>> Thanks,
>> Tim
>>
>>
>>

From: glen walker
Date: Fri, Jun 22 2018 1:48PM
Subject: Re: [EXTERNAL] Navigation in application mode
← Previous message | Next message →

Birkir, when you say that navigation to a grid should automatically switch
to application/forms mode, are you saying a well-behaved screen reader
should do that for you or that the web developer should be forcing it
somehow?

The spec for the grid role doesn't explicitly say a user agent should
switch modes but it does say the author should manage the focus.

When navigating to a grid, NVDA doesn't give an audible notification that
forms mode switched but JAWS does. Using the right arrow after entering a
grid, NVDA just reads character by character whereas JAWS will navigate to
the next grid cell.

So it sounds like JAWS handles the grid as you explained but NVDA does not.




On Fri, Jun 22, 2018 at 11:50 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> I would go with a grid
> http://www.w3.org/TR/wai-aria-practices-1.1/#grid
> Once inside a grid the screen reader should automatically switch to
> application/forms mode passing keys through to the webpage.
> Then you can set up keyboard listeners to respond to the arrow key presses.
> For the JQuery script see this example of an accessible date picker:
> https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker
> I workd with a developer to create this. As it was done in 2014 when
> the grid role was poorly supported we used role="application" to force
> the application mode, I believe that is no longer necessary.
>
>
>
> On 6/22/18, Brandon Keith Biggs < = EMAIL ADDRESS REMOVED = > wrote:
> > Hello,
> > Here is a good design for a calendar:
> > http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%
> 20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm
> >
> > If you want to add in appointments, tell the user how many appointments
> > there are each day and allow them to hit enter to see what is on that day
> > and escape to exit back to the date picker.
> > Thanks,
> >
> > Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
> >
> >
> > On Fri, Jun 22, 2018 at 6:23 AM Tim Harshbarger <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> Instead of using role="application", it would be better to use an ARIA
> >> design pattern that more closely matched the interaction.
> >>
> >> The thing with role="application" is that, while it puts screen reader
> >> users in forms mode, it doesn't really tell us how to get around the
> >> application. So using role="application" for one part of the page is
> not
> >> likely to inform screen reader users that pressing the up and down arrow
> >> keys will move from meeting to meeting and pressing the left and right
> >> arrow keys will move between days.
> >>
> >> A listbox might work because a screen reader user will expect the up and
> >> down arrow keys to move up and down the list. Unfortunately, there is
> >> also
> >> an expectation that using the left and right arrow keys will do the same
> >> exact thing as using the up and down arrow keys. Users would not expect
> >> the left and right arrow keys to move between days. If you used a
> >> listbox,
> >> you likely would need to explicitly inform users of what the left and
> >> right
> >> arrow keys do differently.
> >>
> >> To me, this sounds more like a grid. In a grid, there would likely be
> a
> >> better expectation that the up and down arrow keys would move within the
> >> day while the left and right arrow keys move between days.
> >>
> >> Thanks,
> >> Tim
> >>
> >>
> >>

From: Birkir R. Gunnarsson
Date: Fri, Jun 22 2018 1:53PM
Subject: Re: [EXTERNAL] Navigation in application mode
← Previous message | No next message

The
W3C spec never specifies exactly how a user agent should behave, but
strongly hints at it.
If NVDA does not switch into application mode inside a grid that's an
NVDA bug (unless the grid is marked as readonly).
This is why authors still use the application role on a grid, like we
did with the datepicker, but screen readers should address these
issues. I will go look at NVDA issues and file one if needed.



On 6/22/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Birkir, when you say that navigation to a grid should automatically switch
> to application/forms mode, are you saying a well-behaved screen reader
> should do that for you or that the web developer should be forcing it
> somehow?
>
> The spec for the grid role doesn't explicitly say a user agent should
> switch modes but it does say the author should manage the focus.
>
> When navigating to a grid, NVDA doesn't give an audible notification that
> forms mode switched but JAWS does. Using the right arrow after entering a
> grid, NVDA just reads character by character whereas JAWS will navigate to
> the next grid cell.
>
> So it sounds like JAWS handles the grid as you explained but NVDA does not.
>
>
>
>
> On Fri, Jun 22, 2018 at 11:50 AM, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> I would go with a grid
>> http://www.w3.org/TR/wai-aria-practices-1.1/#grid
>> Once inside a grid the screen reader should automatically switch to
>> application/forms mode passing keys through to the webpage.
>> Then you can set up keyboard listeners to respond to the arrow key
>> presses.
>> For the JQuery script see this example of an accessible date picker:
>> https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker
>> I workd with a developer to create this. As it was done in 2014 when
>> the grid role was poorly supported we used role="application" to force
>> the application mode, I believe that is no longer necessary.
>>
>>
>>
>> On 6/22/18, Brandon Keith Biggs < = EMAIL ADDRESS REMOVED = > wrote:
>> > Hello,
>> > Here is a good design for a calendar:
>> > http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%
>> 20Pickers/ARIA%20Date%20Picker%20(Basic)/demo.htm
>> >
>> > If you want to add in appointments, tell the user how many appointments
>> > there are each day and allow them to hit enter to see what is on that
>> > day
>> > and escape to exit back to the date picker.
>> > Thanks,
>> >
>> > Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
>> >
>> >
>> > On Fri, Jun 22, 2018 at 6:23 AM Tim Harshbarger <
>> > = EMAIL ADDRESS REMOVED = > wrote:
>> >
>> >> Instead of using role="application", it would be better to use an ARIA
>> >> design pattern that more closely matched the interaction.
>> >>
>> >> The thing with role="application" is that, while it puts screen reader
>> >> users in forms mode, it doesn't really tell us how to get around the
>> >> application. So using role="application" for one part of the page is
>> not
>> >> likely to inform screen reader users that pressing the up and down
>> >> arrow
>> >> keys will move from meeting to meeting and pressing the left and right
>> >> arrow keys will move between days.
>> >>
>> >> A listbox might work because a screen reader user will expect the up
>> >> and
>> >> down arrow keys to move up and down the list. Unfortunately, there is
>> >> also
>> >> an expectation that using the left and right arrow keys will do the
>> >> same
>> >> exact thing as using the up and down arrow keys. Users would not
>> >> expect
>> >> the left and right arrow keys to move between days. If you used a
>> >> listbox,
>> >> you likely would need to explicitly inform users of what the left and
>> >> right
>> >> arrow keys do differently.
>> >>
>> >> To me, this sounds more like a grid. In a grid, there would likely be
>> a
>> >> better expectation that the up and down arrow keys would move within
>> >> the
>> >> day while the left and right arrow keys move between days.
>> >>
>> >> Thanks,
>> >> Tim
>> >>
>> >>
>> >>