- From: James Teh <jamie@nvaccess.org>
- Date: Wed, 24 Aug 2016 10:55:38 +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>
- Message-ID: <81e47a08-aec2-c766-de2d-2e12a17a3bab@nvaccess.org>
Hi Rich, From what I can see from the spec, rowindex/colindex are not required to be contiguous. Rows/columns can be completely missing from the DOM. From what I can see, there's no mention that missing cells need to be spanned... unless I'm missing something. That means you can have a cell in row 1 and a cell in row 5 with no cells between, but the cell in row 1 doesn't have to span the gap. Because of this, there's no way to fetch the cell in the row above; subtracting 1 from the row won't work because there's no cell in row 4. This is all fine if the gaps are always spanned, but again, the spec doesn't seem to require this. Jamie On 24/08/2016 5:38 AM, Rich Schwerdtfeger wrote: > Hi Jamie, > > So, unlike aria 1.0 and HTML5 we now have aria-rowindex and > aria-colindex. If cells disappear the indices can be consistent with > the actual table - even when rows or columns are hidden in between > rows and columns respectively. . so, if you have a rowspan in aria and > you happen to hide rows in between you can get the spans to line up > appropriately - provided the author places the indices on. Here is an > example: > > <section role=“table”> > <div role =“row” aria-rowindex=“1” > > <span role=“cell” aria-colindex=“1” aria-colcount=“3 > aria-colspan=“3">foo</span><span > aria-colindex=“4”aria-colcount=“4”>fourth cell</span> > </div> > <div role=“row”> > > If you have cells or rows missing can’t you use the implicit aria row > and column index on the cells to convey the information to the user > and use that information to aid navigation? > > Rich > > Rich Schwerdtfeger > > > > >> On Aug 18, 2016, at 10:08 PM, James Teh <jamie@nvaccess.org >> <mailto:jamie@nvaccess.org>> wrote: >> >> 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 >>>> <mailto: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 <http://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 <http://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 Wednesday, 24 August 2016 00:56:13 UTC