WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Using Aria within a table to indicate that a cell is highlighted

for

From: David Engebretson Jr.
Date: Jul 4, 2022 7:17PM

I agree that documentation is going to be really important. Would that documentation be best in the table legend or in a paragraph before the table?

I think defining a shortcut key, like Glen suggests, could add development overhead that could be avoided as user agents and assistive technologies develop over the years ahead. Too many possibilities for key conflicts in the future.

I, personally, like the idea of making a really descriptive skip link to the data cell that is visually highlighted. I still haven't seen any code from Geethavani.Shamanna so I don't have any context to the problem. I'm just assuming that there is one highlighted data cell the user should obtain focus to. All assumptions I've made from their original email.

Speaking of focus: could the user find focus in that cell with a tabindex set on that data cell? Then an aria-label for screen readers and plenty of other visual goodies for visually oriented folks using assistive technologies other than screen readers and/or keyboard only users of course. I guess that, since you'll need to have an ID for the skip link, you won't need to modify the tab order with tabindex. Probably better that way... but, if all of the data cells are hyperlinks innately then maybe tabindex is the way to go. Hmmm.

Interesting problem. I look forward to hearing more (and seeing some example code) from Geethavani.Shamanna!
David

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen walker
Sent: Monday, July 04, 2022 5:24 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] [EXTERNAL] Using Aria within a table to indicate that a cell is highlighted

If you want to provide a way to jump to highlighted cells (assuming you can have more than one highlighted - or maybe this is a conditional highlighting example where cells of a certain value have a different visual appearance than other cells), then you're probably better off programming the shortcut key yourself so that it's available to all users.

Using headings or aria-current is sort of a hack. Yes, headings allow screen reader users to jump to a place on the page but you're only using a heading to get that feature from the screen reader and the cell isn't really a "heading" for anything, thus why Kevin said it might break 1.3.1, although in kind of the reverse way. Usually 1.3.1 is for having a visual relationship on the page but there isn't a programmatic relationship. The highlighted cell heading is the opposite - you are creating a programmatic relationship when there isn't really a visual relationship. Yes, there's a visual difference for the highlighted cells but that doesn't make the cell a heading.

We did something like this for navigating to landmarks. Screen reader users can easily navigate to landmarks but sighted keyboard users cannot.
It's not built-in to the browser. So we programmed Ctrl+F6 to allow navigating to landmarks. All users could access it. (F6 is a common key for navigating to different parts of an application so we used Ctrl+F6 in a similar vein.)

F2 is a common key for spreadsheets to edit the cell value. You could conceptually create a Ctrl+F2 to navigate to the next highlighted cell.
The two behaviors (F2 and Ctrl+F2) aren't really related so that might be a poor key choice, but it's just an example.

You'd have to be clear in your documentation that that shortcut key exists.