WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA grid versus HTML table

for

From: Mallory
Date: Jul 1, 2020 2:13PM

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 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 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 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 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.
> >> > >> > >> > >> > >>
> >
> > > > >