Re: aria-rowspan, aria-colspan, aria-colindex,aria-colcount, aria-rowindex, aria-colcount, figure (Action 2102)

I must be missing something, but if rows and cells cannot be missed from
the DOM, then what is a point of aria-colindex and aria-rowindex? the
browser could compute indexes on his own.
Alex.

On Tue, Aug 23, 2016 at 9:13 PM, Rich Schwerdtfeger <richschwer@gmail.com>
wrote:

> 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 3306www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: jamie@nvaccess.org
>
>