- From: James Teh <jamie@nvaccess.org>
- Date: Fri, 19 Aug 2016 13:08:46 +1000
- To: Rich Schwerdtfeger <richschwer@gmail.com>
- Cc: Joanmarie Diggs <jdiggs@igalia.com>, Alexander Surkov <asurkov@mozilla.com>, Joseph Scheuhammer <clown@alum.mit.edu>, Accessible Rich Internet Applications Working Group <public-aria@w3.org>
Hi. Yes, an author can hide rows or cells. However, if they do, arguably, the table "looks" as if those cells either never existed or are empty (depending on the method used for hiding). This is just the same for, say, hidden list items; hidden items don't count with respect to group position. Right now, if you display: none a table row, Firefox completely ignores that row for a11y. The problem with non-contiguous cells is that the table interfaces just don't really handle this case well. If you have a 3 by 3 table with row 2 missing, how do you get to the previous row from row 3 column 3? Sure, you can just keep decrementing row until you hit something, but aside from being ugly, that mightn't work where there are merged cells. I agree it'd make sense if we didn't have object attributes as well as the table cell interface. However, if we want that, we need to come up with an efficient method for navigating tables where there are non-contiguous cells. But even if we do that, we have a backwards compat issue because older AT will probably choke on non-contiguous tables. Jamie On 10/08/2016 7:14 AM, Rich Schwerdtfeger wrote: > Jamie, > > Even for an HTML table we cannot guarantee contiguous cells. An author can easily hide an entire row or individual cells. > > So, I don't see why you would put a restriction on these ARIA attributes to only be in object attributes. > > Rich > > Sent from my iPad > >> On Aug 8, 2016, at 5:26 PM, James Teh <jamie@nvaccess.org> wrote: >> >>> On 9/08/2016 6:06 AM, Joanmarie Diggs wrote: >>> I read that. But that's talking about the Table -- and not the TableCell >>> -- interface, right? >> Well, yes, non-contiguous cells are more of a *direct* issue for the table interface, but those two interfaces (table and cell) go hand in hand: they necessarily impact each other. >> >>> If I have a cell, and the TableCell -- not the Table -- interface is >>> implemented for that cell, then I should be able to ask that cell for >>> its span. I don't see how that would be impacted by gaps. >> That depends how you map things. From what I can see, the table interface doesn't really support non-contiguous cells... or at least, it wasn't clear that it would. At the very least, non-contiguous cells will break existing versions of NVDA and probably other AT. My recollection is that it was decided that the table interface should be contiguous and attributes should be used to get the *real* numbers. So, using my example, if you have columns 1 and 4 (2 and 3 are a gap), column 4 gets mapped to column 2 in the table interface. If column 1 says it has a span of 2, we have a problem because the spanned column 2 in the table interface maps to ARIA column 4. >> >> Jamie >> >> -- >> James Teh >> Executive Director, NV Access Limited >> Ph +61 7 3149 3306 >> www.nvaccess.org >> Facebook: http://www.facebook.com/NVAccess >> Twitter: @NVAccess >> SIP: jamie@nvaccess.org >> -- James Teh Executive Director, NV Access Limited Ph +61 7 3149 3306 www.nvaccess.org Facebook: http://www.facebook.com/NVAccess Twitter: @NVAccess SIP: jamie@nvaccess.org
Received on Friday, 19 August 2016 03:09:11 UTC