Re: Flat Hierarchy Grid

Hi Yura,

> Hello everyone,
>
> I wanted to bring up a use case related to the grid role where the 
> grid hierarchy is enforced with CSS rather than markup. It is fairly 
> common among many mobile web applications that use CSS heavily to 
> structure markup into things like lists and grids. The HTML in many 
> cases looks flat, for example:
>
> <section role="grid">
>   <div role="gridcell">Cell 1</div>
>   ...
>   <div role="gridcell">Cell N</div>
> </section>
>
> And the CSS, used to make it look like a grid is:
>
> <style>
>   section div {
>     width: calc(100% / 4);
>     display: inline-block;
>     ...
>   }
> </style>
>
> As you can see, an element with a row role is missing in this case. 
> Which makes it pretty difficult to handle the grid -> role -> gridcell 
> relation since it's enforced exclusively with CSS.
>
> I had a question regarding the strictness of the requirement of having 
> an explicit row container ...

As of ARIA 1.0 that's an author error.  According to the spec, the grid 
role *requires* either a child with role row or with role rowgroup.  See 
the "Characteristics of grid" table at 
http://www.w3.org/WAI/PF/aria/roles#grid, specifcally the "Required 
Owned Elements" row.  Also, the second paragraph begins:

"Authors MUST ensure that elements with role gridcell are owned by 
elements with role row, which in turn are owned by an element with role 
rowgroup, grid or treegrid."

The spec for related roles, such as gridcell, rowheader, colheader, 
etc., the contaninment heirarchy is consistent with the idea that 
authors MUST nest cells within rows.

> ... and I was wondering if it would be reasonable to have an aria-rows 
> and an aria-cols attributes or something similar as an alternative? 
> These attributes could be defined by the author. aria-rows would 
> define the number of rows in the grid and aria-cols would define the 
> number of columns. The browser in this case would be capable of 
> determining the gridcell position within the grid based on those 
> attributes and the actual position in the existing flat markup. The 
> first example then would look like this:
>
> <section role="grid" aria-rows="3" aria-cols="4">
>   <div role="gridcell">Cell 1</div> // Row 1 Column 1
>   ...
>   <div role="gridcell">Cell N</div> // Row 3 Column 4
> </section>
>
> Thanks,
>
> Yura Zenevich 

It's an interesting idea, but I have questions.

1.  Is a grid the correct semantics for the example?  The visual 
rendering as a grid might be purely for layout.  But I can't tell from 
the markup.  Is there an url to see what this looks like? Better still, 
can the markup be loaded into a browser so as to actually experience the 
widget?

2.  If it is a grid, why not put in the requisite row elements?  Let me 
make an analogy: it's like saying that you have a <table>, but you only 
want to have a list of <td> elements without any <tr>s, where the <tr>s 
are handled using CSS.  And, to compensate, you propose a new attribute 
@num-tr:

<table num-tr="3">
   <td>Cell 1</td>
   <td>Cell 2</td>
  ...
   <td>Cell N</td>
</table>

That seems odd just to get the same effect as four <tr>s.

3.  What does the accessibility tree look like for the original 
example?  If there are no rows in the markup, are there rows in the a11y 
tree?  If so, where did they come from?  If not, is that problem?

4.  Both grids and tables have optional row and column headers that are 
children of the row they are contained in.  How would headers fit into 
this new scheme using @aria-rows and @aria-cols?

Hope that helps.

-- 
;;;;joseph.


'A: After all, it isn't rocket science.'
'K: Right. It's merely computer science.'
              - J. D. Klaun -

Received on Wednesday, 28 May 2014 14:53:41 UTC