WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Should NVDA announce "table" when it encounters CSSdisplay:table ?

for

From: Steve Green
Date: Apr 20, 2021 3:49PM

As far as I can tell, browsers are supposed to expose the node as a table.

I expect that JAWS is not announcing it as a table because one of its heuristics is that a data table contains at least two rows and two columns, which your example does not. If you built a table of that size using div elements and the relevant table-cell and table-row roles, JAWS would probably announce it as a table.

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen walker
Sent: 20 April 2021 21:27
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: [WebAIM] Should NVDA announce "table" when it encounters CSS display:table ?

I found a page that has a <div style="display:table">. On Chrome, when I tab to an <input> contained in that <div>, NVDA announces "table" before it announces the input field. JAWS does not say "table".

If I view the accessibility properties in Chrome, it says the role is LayoutTable. A LayoutTable is not a real role with regards to ARIA roles.

Even though NVDA says "table", you can't use any table navigation keys.

I find this quite confusing. Should Chrome not be surfacing that this is a layout table? role="table" isn't specified anywhere. But whether a layout table is correct or not, JAWS seems to ignore it but NVDA does not.

Firefox does not announce "table" so there's no confusion there.

I took a quick look at NVDA bugs in github but didn't see anything offhand, but then I didn't look very hard.

This simple example shows the problem. The two button elements are only there to give me tab stops before and after the input field.

<button>foo</button>
<div style="display:table">
<input>
</div>
<button>foo</button>