E-mail List Archives

Search E-mail List Archives for

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

From: Alan Zaitchik
Date: Tue, Jun 23 2020 8:05AM
Subject: ARIA grid versus HTML table
No previous message | Next message →

I am not sure when or if I would ever need to use the "aria grid" coding
pattern. Every example I have ever seen (WAI-ARIA Authoring, Mozilla
developers network) looks to me like one I could equally well implement in
native HTML5.
When I have coded using the ARIA grid pattern I find anomalous screen
reader behaviors as soon as I deviate from balanced "simple" tables, so
there seems to me to be nothing gained in foregoing strict native table
semantics of HTML.
Am I missing something?
Thanks,
A

From: glen walker
Date: Tue, Jun 23 2020 8:28AM
Subject: Re: ARIA grid versus HTML table
← Previous message | Next message →

I've only used the grid pattern when implementing a spreadsheet type widget
where most cells are editable and it made sense to use arrow keys to
navigate and have the grid be one tab stop. I haven't used the grid as a
layout container.

The majority of the time I use tables.

On Tue, Jun 23, 2020 at 8:06 AM Alan Zaitchik < = EMAIL ADDRESS REMOVED = >
wrote:

> I am not sure when or if I would ever need to use the "aria grid" coding
> pattern. Every example I have ever seen (WAI-ARIA Authoring, Mozilla
> developers network) looks to me like one I could equally well implement in
> native HTML5.
> When I have coded using the ARIA grid pattern I find anomalous screen
> reader behaviors as soon as I deviate from balanced "simple" tables, so
> there seems to me to be nothing gained in foregoing strict native table
> semantics of HTML.
> Am I missing something?
> Thanks,
> A
> > > > >

From: Birkir R. Gunnarsson
Date: Tue, Jun 23 2020 3:02PM
Subject: Re: ARIA grid versus HTML table
← Previous message | Next message →

Glen got it
A grid should be reserved only for fully interactive set of components
(spreadsheets, date pickers), where the whole grid is a single tab
stop and navigation within the grid is implemented using arrow keys.
* Arrow keys are used to navigate between columns and rows in the grid
* All keyboard interaction is fully implemented by the developers


These could just as well be implemented using an application role
instead of a grid. The only advantage of the grid is the ability to
"supposedly" announce column/row header cells as you navigate within
the grid, I believe support for this is pretty spotty so I've opted to
add the applicable header info to individual cells and using the
application role.
See, for instance, the good old accessible Date Picker example from
Deque University
https://dequeuniversity.com/library/aria/date-picker
(I authored the original code with Harris Schneiderman, a serious
front end genius, back in 2014, it may well have been altered since
then, if so certainly for the better, but it was the best screen
reader experience datepicker we could come up with at the time).
We used to use ARIA girds with aria-readonly="true" to build fake data
tables from grids back in the old days, but with the ARIA 1.1 table
role for static data tables that was no longer necessary. The ARIA
table structure actually has surprisingly good screen reader support,
I wrote about it
https://www.24a11y.com/2018/aria-1-1-whats-new/
(it has a link to a Code Pen example I put together), of course using
a real HTML <table> is always best, at least for the desktop.

Finally, many people jump to conclusions and start using the grid role
for a sortable table (table that is static except the column headers
which can be clicked to sort the table), that is a no no, use a
regular table and put button elements inside the column headers.


On 6/23/20, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> I've only used the grid pattern when implementing a spreadsheet type widget
> where most cells are editable and it made sense to use arrow keys to
> navigate and have the grid be one tab stop. I haven't used the grid as a
> layout container.
>
> The majority of the time I use tables.
>
> On Tue, Jun 23, 2020 at 8:06 AM Alan Zaitchik < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> I am not sure when or if I would ever need to use the "aria grid" coding
>> pattern. Every example I have ever seen (WAI-ARIA Authoring, Mozilla
>> developers network) looks to me like one I could equally well implement
>> in
>> native HTML5.
>> When I have coded using the ARIA grid pattern I find anomalous screen
>> reader behaviors as soon as I deviate from balanced "simple" tables, so
>> there seems to me to be nothing gained in foregoing strict native table
>> semantics of HTML.
>> Am I missing something?
>> Thanks,
>> A
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Brandon Keith Biggs
Date: Tue, Jun 23 2020 3:07PM
Subject: Re: ARIA grid versus HTML table
← Previous message | Next message →

I like the grid element because of the UX it can provide, You can either
choose to navigate it like a normal table, or pass key commands to the
application, and navigate through the cells with the arrow keys. It is
really important that the UX for the table is built well though, with
ctrl+home and end, page up and down, ctrl+shift+arrow keys....
I like to use:
https://vaadin.com/components/vaadin-grid/html-examples
It can be used like a spreadsheet or a normal table, it's up to the user.
Thanks,

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


On Tue, Jun 23, 2020 at 2:02 PM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Glen got it
> A grid should be reserved only for fully interactive set of components
> (spreadsheets, date pickers), where the whole grid is a single tab
> stop and navigation within the grid is implemented using arrow keys.
> * Arrow keys are used to navigate between columns and rows in the grid
> * All keyboard interaction is fully implemented by the developers
>
>
> These could just as well be implemented using an application role
> instead of a grid. The only advantage of the grid is the ability to
> "supposedly" announce column/row header cells as you navigate within
> the grid, I believe support for this is pretty spotty so I've opted to
> add the applicable header info to individual cells and using the
> application role.
> See, for instance, the good old accessible Date Picker example from
> Deque University
> https://dequeuniversity.com/library/aria/date-picker
> (I authored the original code with Harris Schneiderman, a serious
> front end genius, back in 2014, it may well have been altered since
> then, if so certainly for the better, but it was the best screen
> reader experience datepicker we could come up with at the time).
> We used to use ARIA girds with aria-readonly="true" to build fake data
> tables from grids back in the old days, but with the ARIA 1.1 table
> role for static data tables that was no longer necessary. The ARIA
> table structure actually has surprisingly good screen reader support,
> I wrote about it
> https://www.24a11y.com/2018/aria-1-1-whats-new/
> (it has a link to a Code Pen example I put together), of course using
> a real HTML <table> is always best, at least for the desktop.
>
> Finally, many people jump to conclusions and start using the grid role
> for a sortable table (table that is static except the column headers
> which can be clicked to sort the table), that is a no no, use a
> regular table and put button elements inside the column headers.
>
>
> On 6/23/20, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> > I've only used the grid pattern when implementing a spreadsheet type
> widget
> > where most cells are editable and it made sense to use arrow keys to
> > navigate and have the grid be one tab stop. I haven't used the grid as a
> > layout container.
> >
> > The majority of the time I use tables.
> >
> > On Tue, Jun 23, 2020 at 8:06 AM Alan Zaitchik < = EMAIL ADDRESS REMOVED = >
> > wrote:
> >
> >> I am not sure when or if I would ever need to use the "aria grid" coding
> >> pattern. Every example I have ever seen (WAI-ARIA Authoring, Mozilla
> >> developers network) looks to me like one I could equally well implement
> >> in
> >> native HTML5.
> >> When I have coded using the ARIA grid pattern I find anomalous screen
> >> reader behaviors as soon as I deviate from balanced "simple" tables, so
> >> there seems to me to be nothing gained in foregoing strict native table
> >> semantics of HTML.
> >> Am I missing something?
> >> Thanks,
> >> A
> >> > >> > >> > >> > >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Alan Zaitchik
Date: Wed, Jul 01 2020 12:09PM
Subject: Re: ARIA grid versus HTML table
← Previous message | Next message →

Thank you, all.
Why do I see so many examples where the grid role is assigned to
HTML table elements? Even WAI-ARIA Authoring Guidelines does this with their data grid examples.
If you're writing key event handlers for grid behavior you coukd just have them work with tables without the grid role, so what's gained by adding grid role?

> On Jun 23, 2020, at 17:07, Brandon Keith Biggs < = EMAIL ADDRESS REMOVED = > wrote:
>
> I like the grid element because of the UX it can provide, You can either
> choose to navigate it like a normal table, or pass key commands to the
> application, and navigate through the cells with the arrow keys. It is
> really important that the UX for the table is built well though, with
> ctrl+home and end, page up and down, ctrl+shift+arrow keys....
> I like to use:
> https://vaadin.com/components/vaadin-grid/html-examples
> It can be used like a spreadsheet or a normal table, it's up to the user.
> Thanks,
>
> Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
>
>
>> On Tue, Jun 23, 2020 at 2:02 PM Birkir R. Gunnarsson <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>> Glen got it
>> A grid should be reserved only for fully interactive set of components
>> (spreadsheets, date pickers), where the whole grid is a single tab
>> stop and navigation within the grid is implemented using arrow keys.
>> * Arrow keys are used to navigate between columns and rows in the grid
>> * All keyboard interaction is fully implemented by the developers
>>
>>
>> These could just as well be implemented using an application role
>> instead of a grid. The only advantage of the grid is the ability to
>> "supposedly" announce column/row header cells as you navigate within
>> the grid, I believe support for this is pretty spotty so I've opted to
>> add the applicable header info to individual cells and using the
>> application role.
>> See, for instance, the good old accessible Date Picker example from
>> Deque University
>> https://dequeuniversity.com/library/aria/date-picker
>> (I authored the original code with Harris Schneiderman, a serious
>> front end genius, back in 2014, it may well have been altered since
>> then, if so certainly for the better, but it was the best screen
>> reader experience datepicker we could come up with at the time).
>> We used to use ARIA girds with aria-readonly="true" to build fake data
>> tables from grids back in the old days, but with the ARIA 1.1 table
>> role for static data tables that was no longer necessary. The ARIA
>> table structure actually has surprisingly good screen reader support,
>> I wrote about it
>> https://www.24a11y.com/2018/aria-1-1-whats-new/
>> (it has a link to a Code Pen example I put together), of course using
>> a real HTML <table> is always best, at least for the desktop.
>>
>> Finally, many people jump to conclusions and start using the grid role
>> for a sortable table (table that is static except the column headers
>> which can be clicked to sort the table), that is a no no, use a
>> regular table and put button elements inside the column headers.
>>
>>
>>> On 6/23/20, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>>> I've only used the grid pattern when implementing a spreadsheet type
>> widget
>>> where most cells are editable and it made sense to use arrow keys to
>>> navigate and have the grid be one tab stop. I haven't used the grid as a
>>> layout container.
>>>
>>> The majority of the time I use tables.
>>>
>>> On Tue, Jun 23, 2020 at 8:06 AM Alan Zaitchik < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>> I am not sure when or if I would ever need to use the "aria grid" coding
>>>> pattern. Every example I have ever seen (WAI-ARIA Authoring, Mozilla
>>>> developers network) looks to me like one I could equally well implement
>>>> in
>>>> native HTML5.
>>>> When I have coded using the ARIA grid pattern I find anomalous screen
>>>> reader behaviors as soon as I deviate from balanced "simple" tables, so
>>>> there seems to me to be nothing gained in foregoing strict native table
>>>> semantics of HTML.
>>>> Am I missing something?
>>>> Thanks,
>>>> A
>>>> >>>> >>>> >>>> >>>>
>>> >>> >>> >>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> >> >>
>

From: Mallory
Date: Wed, Jul 01 2020 2:13PM
Subject: Re: ARIA grid versus HTML table
← Previous message | Next message →

I would like to know this as well.

When we added grid roles to, for example, calendars, all the table semantics were gone (overridden) and we could not navigate them like tables (column and row headers would not announce as you moved around either). We ended up being forced to add aria-labels with all the column headers as well as cell data on every cell, which seemed like reinventing wheels.

However, adding javascript to a table means screen reader users can use table navigation but they'd have to know to go into application mode to get the intended keyboarding of a grid. Throwing an application role on the thing forces the intended keyboarding but removes the usual table and navving abilities (and so I'd rather not). Since these things usually have either every cell or most cells focusable, the intended keyboard pattern is more than a nice-to-have (prevent needing a Thousand Tabs of Death to get through or past them).

_mallory

On Wed, Jul 1, 2020, at 8:09 PM, Alan Zaitchik wrote:
> Thank you, all.
> Why do I see so many examples where the grid role is assigned to
> HTML table elements? Even WAI-ARIA Authoring Guidelines does this with
> their data grid examples.
> If you're writing key event handlers for grid behavior you coukd just
> have them work with tables without the grid role, so what's gained by
> adding grid role?
>
> > On Jun 23, 2020, at 17:07, Brandon Keith Biggs < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > I like the grid element because of the UX it can provide, You can either
> > choose to navigate it like a normal table, or pass key commands to the
> > application, and navigate through the cells with the arrow keys. It is
> > really important that the UX for the table is built well though, with
> > ctrl+home and end, page up and down, ctrl+shift+arrow keys....
> > I like to use:
> > https://vaadin.com/components/vaadin-grid/html-examples
> > It can be used like a spreadsheet or a normal table, it's up to the user.
> > Thanks,
> >
> > Brandon Keith Biggs <http://brandonkeithbiggs.com/>;
> >
> >
> >> On Tue, Jun 23, 2020 at 2:02 PM Birkir R. Gunnarsson <
> >> = EMAIL ADDRESS REMOVED = > wrote:
> >>
> >> Glen got it
> >> A grid should be reserved only for fully interactive set of components
> >> (spreadsheets, date pickers), where the whole grid is a single tab
> >> stop and navigation within the grid is implemented using arrow keys.
> >> * Arrow keys are used to navigate between columns and rows in the grid
> >> * All keyboard interaction is fully implemented by the developers
> >>
> >>
> >> These could just as well be implemented using an application role
> >> instead of a grid. The only advantage of the grid is the ability to
> >> "supposedly" announce column/row header cells as you navigate within
> >> the grid, I believe support for this is pretty spotty so I've opted to
> >> add the applicable header info to individual cells and using the
> >> application role.
> >> See, for instance, the good old accessible Date Picker example from
> >> Deque University
> >> https://dequeuniversity.com/library/aria/date-picker
> >> (I authored the original code with Harris Schneiderman, a serious
> >> front end genius, back in 2014, it may well have been altered since
> >> then, if so certainly for the better, but it was the best screen
> >> reader experience datepicker we could come up with at the time).
> >> We used to use ARIA girds with aria-readonly="true" to build fake data
> >> tables from grids back in the old days, but with the ARIA 1.1 table
> >> role for static data tables that was no longer necessary. The ARIA
> >> table structure actually has surprisingly good screen reader support,
> >> I wrote about it
> >> https://www.24a11y.com/2018/aria-1-1-whats-new/
> >> (it has a link to a Code Pen example I put together), of course using
> >> a real HTML <table> is always best, at least for the desktop.
> >>
> >> Finally, many people jump to conclusions and start using the grid role
> >> for a sortable table (table that is static except the column headers
> >> which can be clicked to sort the table), that is a no no, use a
> >> regular table and put button elements inside the column headers.
> >>
> >>
> >>> On 6/23/20, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> >>> I've only used the grid pattern when implementing a spreadsheet type
> >> widget
> >>> where most cells are editable and it made sense to use arrow keys to
> >>> navigate and have the grid be one tab stop. I haven't used the grid as a
> >>> layout container.
> >>>
> >>> The majority of the time I use tables.
> >>>
> >>> On Tue, Jun 23, 2020 at 8:06 AM Alan Zaitchik < = EMAIL ADDRESS REMOVED = >
> >>> wrote:
> >>>
> >>>> I am not sure when or if I would ever need to use the "aria grid" coding
> >>>> pattern. Every example I have ever seen (WAI-ARIA Authoring, Mozilla
> >>>> developers network) looks to me like one I could equally well implement
> >>>> in
> >>>> native HTML5.
> >>>> When I have coded using the ARIA grid pattern I find anomalous screen
> >>>> reader behaviors as soon as I deviate from balanced "simple" tables, so
> >>>> there seems to me to be nothing gained in foregoing strict native table
> >>>> semantics of HTML.
> >>>> Am I missing something?
> >>>> Thanks,
> >>>> A
> >>>> > >>>> > >>>> > >>>> > >>>>
> >>> > >>> > >>> > >>> > >>>
> >>
> >>
> >> --
> >> Work hard. Have fun. Make history.
> >> > >> > >> > >> > >>
> >
> > > > >

From: glen walker
Date: Wed, Jul 01 2020 2:48PM
Subject: Re: ARIA grid versus HTML table
← Previous message | No next message

If your calendar is an editable object, such as the outlook calendar or
google calendar, where each day is an interactive cell (because you can add
event details), then I can see the grid role being used. But if your
calendar is for choosing a date (such as a hotel or airline calendar), then
the grid is not appropriate.

If grid is being used so that you don't have to tab through every cell in
the table, I don't think that's an appropriate use of grid. The "gridness"
should be decided based on the interaction with the table cells and not
keyboard navigation.

If you think it'll be a pain to tab through all the cells of a calendar but
using grid is not appropriate, you can have a "skip over" link before the
calendar that allows the user to jump over the calendar to the next
interactive element.

On Wed, Jul 1, 2020 at 2:13 PM Mallory < = EMAIL ADDRESS REMOVED = > wrote:

> I would like to know this as well.
>
> When we added grid roles to, for example, calendars, all the table
> semantics were gone (overridden) and we could not navigate them like tables
>