- From: Rich Schwerdtfeger <richschwer@gmail.com>
- Date: Tue, 23 Aug 2016 20:13:29 -0500
- To: James Teh <jamie@nvaccess.org>
- 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: <105A5526-AD43-43F0-9C1D-6F4F03E224AA@gmail.com>
Thanks Jamie, No, you are not missing anything. The issue of missing rows and columns was not raised. We could modify the spec., but could these issues be addressed with authoring guidelines? Rich Rich Sent from my iPhone > On Aug 23, 2016, at 7:55 PM, James Teh <jamie@nvaccess.org> wrote: > > 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> 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> 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 > > -- > 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 01:14:00 UTC