Develop example of tree grid design pattern

[mcking65]

This issue depends on issue #91.

URL for Viewing Development Branch

This example is being developed in the treegrid branch. View it at:
https://rawgit.com/w3c/aria-practices/treegrid/examples/treegrid/treegrid-1.html

[aleventhal]

Here's an example I coded up:
https://github.com/aleventhal/treegrid-example

[aleventhal]

Better example, with more discoverable keyboard model:
https://github.com/aleventhal/treegrid-tab-active-cells

[mcking65]

Current work on this example is now in the treegrid branch of w3c/aria-practices at:
https://rawgit.com/w3c/aria-practices/treegrid/examples/treegrid/treegrid-1.html

[mcking65]

In pull request #710, @jongund is working on modifying the example in the treeggrid branch, which is at:
https://rawgit.com/w3c/aria-practices/treegrid/examples/treegrid/treegrid-1.html
to complete the example documentation using the standard example template.

Jon's work can be previewed at:
https://rawgit.com/jongund/aria-practices/treegrid/examples/treegrid/treegrid-1.html

[mcking65]

@aleventhal, what is the reason for using aria-hidden in the treegrid?

[aleventhal]

@mcking65 I believe aria-hidden is just used for the collapsed rows which are hidden. Just semantically indicating that they are in fact hidden.

[mcking65]

@aleventhal commented:

I believe aria-hidden is just used for the collapsed rows which are hidden. Just semantically indicating that they are in fact hidden.

Thanks ... It sounds like we should remove it then.

[aleventhal]

@mcking65 Why is that? Does it work better with the virtual buffer?

[mcking65]

@aleventhal, no, just because it does not do anything; it is redundant code.

In order to avoid the risk of aria-hidden unintentionally hiding things in the event it were somehow to get out of sync, we have adopted the practice of avoiding using aria-hidden at all unless it is necessary to hide something from AT that is visually rendered -- a practice we also avoid like the plague.

[jongund]

I can update the code to not use aria-hidden, will use the class name "hidden".

[jongund]

I have updated the code to remove the use of aria-hidden attribute and should be available as part of pull request 710

[annabbott]

HTML Source Code > HTML Source Code > aria-level="3" > aria-posinset="1" currently is:
Sometimes they are more like trees, otherse are more like grids

Edit necessary: remove last 'e' in 'otherse':
Sometimes they are more like trees, others are more like grids

[annabbott]

Example:
Focus rectangle for Summary cell overlaps into Email cell in rows 3 through 8.

[annabbott]

Example:
Focus rectangle for Subject cell overlaps into Summary cell in rows 7 and 8.

[annabbott]

Example:
Email underline exceeds right edge of visible grid in rows 5 and 7.

[annabbott]

Keyboard support > Shift + Tab | If a cell is focused, moves focus to the previous interactive cell in the current row.

With focus on a cell in the Summary column, shift+tab focuses that entire row. This doesn't agree with the defined Keyboard support.

[annabbott]

Keyboard support >

Control + Home | Moves focus to the first row.
If a cell was focused, focus is kept in the same column, otherwise the entire first row is focused.
Control + End | Moves focus to the last row.
If a cell was focused, focus is kept in the same column, otherwise the entire last row is focused.

Both the above sets need to define what currently has focus prior to key press. Plus both state "kept in the same column" but fail to indicate what in the column gets focus on the key press.

[annabbott]

No further issues noted.

[charmarkk]

Example Useage Options:

Edit necessary: "Example Usage Options." Remove the first e.

Looks to me like Ann got most other things!

[mar10]

Hello,

Sorry if this is off-topic here. Please let me know if there is a better place to discuss this.

I am maintaining a treeview/treegrid control and made an experimental extension that should
follow your recommendations. (It is not yet complete, for example the Tab behavior is different.)
However, one common use case for my treegrid involves embedded controls (dropdown, checkbox,
numeric or text input):

http://wwwendt.de/tech/fancytree/demo/sample-aria-treegrid.html

Using Up, Down, Left, Right to navigate to a
cell is straight forward. A checkbox may then be toggled using the default action
(Space, Enter). However a dropdown or numeric input are controlled
by those navigation keys as well. This may leave the user 'caught' inside a numeric cell.
(I already experimented with a variant, where I distinguish cell-navigation and cell-edit
solve this.)
I am wondering if your specification will cover this scenarios, or if you have any
recommendations?

[accdc]

Hi Matt, it looks good.

There is one thing missing though, which is the explicit column header cell associations, which is necessary for these to be conveyable when navigating the treegrid in modalities like Forms or Application Mode. This is needed in cases where treegrid cells include numerical data like population counts, averages, statistical data, and the only way to know what is meant by the data is to also announce the column header as well during navigation.

So, aria-describedby needs to be added to each role=gridcell node to reference the associated column header cell.

Other than that, it looks great to me.

[mcking65]

In commit 9cb57de, I addressed the editorial feedback from @annabbott and @charmarkk. Most was straight forward. What I changed to address this comment from @annabbott requires some explanation:

Keyboard support > Shift + Tab | If a cell is focused, moves focus to the previous interactive cell in the current row.

With focus on a cell in the Summary column, shift+tab focuses that entire row. This doesn't agree with the defined Keyboard support.

Actually, the behavior matches the documentation, but the documentation was not clear. What is meant by interactive cell, was actually interactive widget, e.g., link, button, etc. When focus is on the summary cell, there are no previous interactive widgets in the row. The only interactive widget in any of the rows is the email address link.

I made two changes to clear this up. First, I added a note in front of the keyboard table. I recently added the same note to the layout grid examples to address a similar issue. The note reads:

NOTE: The following table includes descriptions of how keyboard commands move focus among cells and rows in the treegrid implementation on this page. In the example on this page, some cells contain a single focusable widget, and if a cell contains a widget, the cell is not focusable; the widget receives focus instead of the cell. So, when a keyboard command description says a command moves focus to a cell, the command may either focus the cell or a widget inside the cell.

Second, I changed the tab and shift+tab descriptions:

Tab

• Moves focus to the next interactive widget in the current row.
• If there are no more interactive widgets in the current row, moves focus out of the treegrid.

Shift + Tab

• If a cell is focused, moves focus to the previous interactive widget in the current row.
• If a row is focused, moves focus out of the treegrid.
  list end

[mcking65]

@accdc commented:

There is one thing missing though, which is the explicit column header cell associations, which is necessary for these to be conveyable when navigating the treegrid in modalities like Forms or Application Mode. This is needed in cases where treegrid cells include numerical data like population counts, averages, statistical data, and the only way to know what is meant by the data is to also announce the column header as well during navigation.

So, aria-describedby needs to be added to each role=gridcell node to reference the associated column header cell.

Bryan, given this is a simple grid with explicitly declared column headers, I don't understand why we would need to add a redundant relationship. It would make sense if it was a complex grid where assistive technologies would not be able to determine the header for a cell, but that is not the case here. The spec says:

The columnheader establishes a relationship between it and all cells in the corresponding column. It is the structural equivalent to an HTML th element with a column scope.

In the gridcell role description, the spec says:

If an author intends a gridcell to have a row header, column header, or both, and if the relevant headers cannot be determined from the DOM structure, authors SHOULD explicitly indicate which header cells are relevant to the gridcell by applying aria-describedby on the gridcell and referencing elements with role rowheader or columnheader.

We could make a separate example based on a complex treegrid made from divs rather than a table element that illustrates and tests use of aria-describedby to establish header relationships. However, this example is illustrating and testing support for a treegrid where the relationship should be determined from the DOM structure.

[mcking65]

@mar10 commented:

I am maintaining a treeview/treegrid control and made an experimental extension that should follow your recommendations. (It is not yet complete, for example the Tab behavior is different.) However, one common use case for my treegrid involves embedded controls (dropdown, checkbox, numeric or text input):

http://wwwendt.de/tech/fancytree/demo/sample-aria-treegrid.html

Using Up, Down, Left, Right to navigate to a cell is straight forward. A checkbox may then be toggled using the default action (Space, Enter). However a dropdown or numeric input are controlled by those navigation keys as well. This may leave the user 'caught' inside a numeric cell.

(I already experimented with a variant, where I distinguish cell-navigation and cell-edit solve this.) I am wondering if your specification will cover this scenarios, or if you have any recommendations?

Martin, does the information in the section of the grid pattern titled Keyboard Interaction - Setting Focus and Navigating Inside Cells help? The treegrid pattern references that section in a note in the keyboard section.

[mcking65]

Thanks all for all the awesome work on this example. I'm closing this issue and starting wide review with a new review issue, 790. 790 will include links to any known issues, of which we have one now.

@accdc, if you disagree with my statements regarding aria-describedby, feel free to comment further in this issue or open a separate issue that we can reference from 790.

[mar10]

@mcking65 thanks for the pointers, I wasn't aware of this. Interestingly it is pretty similar to what I tried out with my 'extended' mode. I think I am going to implement this way and enable it by default.

[shirsha]

@mcking65, Iam looking the tree grid example at the following URL:

Keyboard navigation is very confusing.
Normal tendency for a keyboard user is select [enter] key when the focus is on the first row. Here user need to use left and right arrows to expand and collapse when focus is on the whole row.

If user selects right arrow twice then the focus is shifted to each cell and now the user can expand and collapse using [enter] key.
It might confuse the keyboard only user by providing different navigation in the same widget.
It is difficult to use the tree grid widget without reading the instructions given in the keyboard support.

Can we change the navigation in the widget as follows:
If a row is focused, [enter] can expand/ collapse the current row.
Focus stays on current row.
Right arrow shifts the focus to the first cell in the row.