Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop example of tree grid design pattern #132

Closed
mcking65 opened this issue Oct 17, 2016 · 27 comments
Closed

Develop example of tree grid design pattern #132

mcking65 opened this issue Oct 17, 2016 · 27 comments
Assignees
Labels
Example Page Related to a page containing an example implementation of a pattern

Comments

@mcking65
Copy link
Contributor

mcking65 commented Oct 17, 2016

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

@mcking65 mcking65 added this to the 1.1 PR milestone Oct 17, 2016
@mcking65 mcking65 added the Example Page Related to a page containing an example implementation of a pattern label Oct 17, 2016
@aleventhal
Copy link

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

@aleventhal
Copy link

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

mcking65 pushed a commit that referenced this issue Apr 19, 2017
For issue #132, this commit includes:

* Initial implementation of an example treegrid with primarily tree-like behaviors.
* Partial draft of example page content explaining the implementation.
@mcking65
Copy link
Contributor Author

mcking65 commented Apr 19, 2017

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 added a commit that referenced this issue Apr 21, 2017
…ells can be focused (pull #369)

For issue #132: If the treegrid is configured so that rows can not be focused, then the first cell controls the expand/collapse behavior. In this case, aria-expanded will be on the first cell in each row instead of on the row.
@mcking65
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@aleventhal
Copy link

@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
Copy link
Contributor Author

@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
Copy link

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

@mcking65
Copy link
Contributor Author

@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
Copy link
Contributor

jongund commented Jun 15, 2018

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

@jongund
Copy link
Contributor

jongund commented Jun 15, 2018

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

mcking65 pushed a commit that referenced this issue Jun 18, 2018
…n (pull #710)

For issue #132 to develop treegrid example:

* Converted documentation to standard APG template format.
* Filled in documentation gaps.
* Changed treegrid label.
* removed use of aria-hidden.
mcking65 added a commit that referenced this issue Jul 12, 2018
For issue #132, adds an example of the treegrid pattern.
michael-n-cooper pushed a commit that referenced this issue Jul 13, 2018
For issue #132, adds an example of the treegrid pattern.
@annabbott
Copy link

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
Copy link

annabbott commented Jul 17, 2018

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

@annabbott
Copy link

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

@annabbott
Copy link

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

@annabbott
Copy link

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
Copy link

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
Copy link

No further issues noted.

@charmarkk
Copy link
Contributor

charmarkk commented Jul 17, 2018

Example Useage Options:

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

Looks to me like Ann got most other things!

@mar10
Copy link

mar10 commented Jul 17, 2018

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
Copy link

accdc commented Jul 19, 2018

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 added a commit that referenced this issue Jul 19, 2018
Revised examples/treegrid/treegrid-1.html based on feedback from @annabbott and @charmarkk in issue #132.
@mcking65
Copy link
Contributor Author

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

@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
Copy link
Contributor Author

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
Copy link

mar10 commented Jul 20, 2018

@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
Copy link

shirsha commented Jul 25, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Example Page Related to a page containing an example implementation of a pattern
Projects
None yet
Development

No branches or pull requests

8 participants