WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA grid versus HTML table


From: Brandon Keith Biggs
Date: Jun 23, 2020 3:07PM

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:
It can be used like a spreadsheet or a normal table, it's up to the user.

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