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.

Sign up for GitHub

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

Jump to bottom

Draft tree grid design pattern #91

Closed
mcking65 opened this issue Aug 14, 2016 · 18 comments
Closed

Draft tree grid design pattern #91

mcking65 opened this issue Aug 14, 2016 · 18 comments
Labels
Pattern Page Related to a page documenting a Pattern
Milestone
1.1 APG Release 2

Comments

@mcking65
Copy link
Contributor

When working on this issue, there is some old content that may be useful in the file aria-practices-DeletedSectionsArchive.html.

The relevant section can be seen here:
https://rawgit.com/w3c/aria-practices/master/aria-practices-DeletedSectionsArchive.html#treegrid
@mcking65 mcking65 added this to the 1.1 PR milestone Aug 14, 2016
mcking65 added a commit that referenced this issue Aug 14, 2016
@mcking65
Removed sections that require major rework to fix incorrect guidance.
eabf6ca 
In addition to the below, This commit also moves the landmark section after the example section.

Moved each of the following sections from aria-practices.html to aria-practices-DeletedSectionsArchive.html
and created associated issues for drafting new versions.
1. Section "General Steps for Building an Accessible Widget with WAI-ARIA" and created issue #73.
2. Section "Other Widget Authoring Practices"., primarily about aria-valuenow, there is no specific need to raise an issue for this section.
3. Section "Relationships" and raised issues #74, #75, #76, and #77.
4. Section "Managing Dynamic Changes" and created issue #78.
5. Section "Presentation Role" and created issue #79.
6. Section "Form Properties" and created issue #80.
7. Section "Drag-and-Drop Support" and created issue #81
8. Section "Math" and created issue #82.
9. Section "Reusable Component Libraries" and created issue #83.
10. The following 4 Appendix sections related to background on ARIA and created issue #84
A. Background on WAI-ARIA
B. Filling the Gaps for Content Delivered to Desktop Browsers
c. Building Accessible Applications with WAI-ARIA
D. Reasons for Adopting WAI-ARIA
11. The following design patterns:
A. Accordion and updated issue #53.
B. Autocomplete and updated issue #31.
C. Combobox and updated issue #31.
D. Datepicker and updated issue #57
E. Dialog (Non-Modal) and updated issue 59.
F. Dialog (Tooltip) and added issue #85.
G. Landmarks and added issue #86.
H. Popup Help (aka Bubble Help) and added issue #87.
I. Rich Text Editor and added issue #88.
j. Site Navigator - General and added issue #89.
K. Site Navigator - Tree and added it to issue #89.
L. Site Navigator - Tabbed Style and added it to issue #89.
M. Tree Grid and added issue #91.
N. Wizard and added issue #92.
@mcking65 mcking65 modified the milestones: 1.1 Q4 PWD, 1.1 PR Aug 15, 2016
tatermelon pushed a commit to tatermelon/aria-practices that referenced this issue Aug 19, 2016
@mcking65 @tatermelon
Removed sections that require major rework to fix incorrect guidance.
572cdf3 
In addition to the below, This commit also moves the landmark section after the example section.

Moved each of the following sections from aria-practices.html to aria-practices-DeletedSectionsArchive.html
and created associated issues for drafting new versions.
1. Section "General Steps for Building an Accessible Widget with WAI-ARIA" and created issue w3c#73.
2. Section "Other Widget Authoring Practices"., primarily about aria-valuenow, there is no specific need to raise an issue for this section.
3. Section "Relationships" and raised issues w3c#74, w3c#75, w3c#76, and w3c#77.
4. Section "Managing Dynamic Changes" and created issue w3c#78.
5. Section "Presentation Role" and created issue w3c#79.
6. Section "Form Properties" and created issue w3c#80.
7. Section "Drag-and-Drop Support" and created issue w3c#81
8. Section "Math" and created issue w3c#82.
9. Section "Reusable Component Libraries" and created issue w3c#83.
10. The following 4 Appendix sections related to background on ARIA and created issue w3c#84
A. Background on WAI-ARIA
B. Filling the Gaps for Content Delivered to Desktop Browsers
c. Building Accessible Applications with WAI-ARIA
D. Reasons for Adopting WAI-ARIA
11. The following design patterns:
A. Accordion and updated issue w3c#53.
B. Autocomplete and updated issue w3c#31.
C. Combobox and updated issue w3c#31.
D. Datepicker and updated issue w3c#57
E. Dialog (Non-Modal) and updated issue 59.
F. Dialog (Tooltip) and added issue w3c#85.
G. Landmarks and added issue w3c#86.
H. Popup Help (aka Bubble Help) and added issue w3c#87.
I. Rich Text Editor and added issue w3c#88.
j. Site Navigator - General and added issue w3c#89.
K. Site Navigator - Tree and added it to issue w3c#89.
L. Site Navigator - Tabbed Style and added it to issue w3c#89.
M. Tree Grid and added issue w3c#91.
N. Wizard and added issue w3c#92.
@mcking65 mcking65 mentioned this issue Oct 17, 2016
Closed
@jnurthen jnurthen modified the milestones: 1.1 PR, 1.1 Q4 PWD Oct 17, 2016
@mcking65 mcking65 added documentation Pattern Page Related to a page documenting a Pattern labels Jan 19, 2017
@wendyabc
Copy link

Tree Grid isn't in the new draft. What's the plan for it returning in future drafts? This is a pattern we rely on and use quite a lot.

@mcking65
Copy link
Contributor Author

@wendyabc wrote:

This is a pattern we rely on and use quite a lot.

You are just the person I was hoping would show up! Perhaps you can help? Do you have functional, accessible treegrids?

Completing the treegrid pattern is in the Authoring Practices Task Force milestone plan for the version of ARIA Authoring Practices that will be published when ARIA 1.1 becomes a recommendation. That said, I am not 100% confident we will have it baked by then. There are quite a few issues to work out with treegrid.

The ARIA 1.0 treegrid pattern referenced above was deleted because following it would be problematic.

  • It contains keyboard guidance that appears to be both incomplete and unconventional, e.g., ctrl+right to expand.
  • The roles, states, and properties guidance is also incomplete and contains guidance regarding aria-readonly that is not consistent with ARIA 1.1 clarifications about the meaning of aria-readonly in the grid context.
  • It refers to two examples, neither of which are accessible.

@aleventhal
Copy link

I can help work on this.

I need this now for an accessible tool I'm developing called automation inspector, for inspecting the Chrome Automation API. It uses a 3rd party library for the treegrid called FancyTree, which has good keyboard + ARIA for regular trees, and makes an attempt at access for treegrids.

@aleventhal
Copy link

CC'ing @robdodson and @surma

Here is a proposal:

  • left/right for collapse expand because that is by far what is most expected among users for trees.
  • the keystroke for move by word on the given platform to move between columns (ctrl+left/right on windows, alt+left/right on mac). I believe there have been implementations that have done this before in mail clients, I'll check into it.
  • Ideally, a screen reader should begin reading from the current cell to the end of the given row.
    Worst case, if a user does not discover the command to move by cell, they will still be able to move by row, expand/collapse, and hear all the information available. The move by cell command which is harder to know about is helpful for reducing the amount of TTS, but not as important.

Screen readers may not do the "read to the end" behavior automatically. Therefore, may be advisable to have the entire row focused when the user is focused on the first column. That would allow us to get most of the behavior we need in today's screen readers.

@aleventhal aleventhal mentioned this issue Mar 31, 2017
Closed
@aleventhal
Copy link

Here are more detailed thoughts on the design pattern and an example:
https://github.com/aleventhal/treegrid-example

@aleventhal
Copy link

I decided that move-by-word isn't as discoverable as it needs to be. Instead, the user can tab to active cells in the current row with the tab key.
Here's an example of this:
https://github.com/aleventhal/treegrid-tab-active-cells
Screen readers would use the built-in table navigation feature of their AT to navigate non-interactive cells.

mcking65 added a commit that referenced this issue Apr 17, 2017
@mcking65
Stub out treegrid pattern and example page for issue #91 and issue 132.
3a85c1c 
1. Modified aria-practices:
    * Add placeholder section for treegrid design pattern.
    * Add link to treegrid example page.
2. Add new template file: examples/treegrid/css/treegrid.css
3. Add nnew template file: examples/treegrid/js/treegrid.js
4. Add new template file:   examples/treegrid/treegrid-1.html
@jongund jongund self-assigned this Jun 15, 2018
@jongund
Copy link
Contributor

jongund commented Jun 15, 2018

I submitted a draft as pull request 714

mcking65 pushed a commit that referenced this issue Jun 18, 2018
@jongund @mcking65
Treegrid Design Pattern: Initial draft (pull #714)
2025725 
For issue #91, add a draft of pattern section for treegrid.
mcking65 pushed a commit that referenced this issue Jun 24, 2018
@jongund @mcking65
Treegrid Design Pattern: Initial draft (pull #714)
9297330 
For issue #91, add a draft of pattern section for treegrid.
@annabbott
Copy link

annabbott commented Jul 17, 2018 •
edited
Loading

Design pattern > Keyboard Interaction For Data Grids > Left arrow > fourth bullet currently is:
If focus is on a first cell in the row and row focus is not supported,focus does not move.

Edit necessary: add space after comma:
If focus is on a first cell in the row and row focus is not supported, focus does not move.

@annabbott
Copy link

annabbott commented Jul 17, 2018 •
edited
Loading

Design pattern > Keyboard Interaction For Data Grids > Left arrow > fifth bullet currently is:
If focus is on a any other cell, focus one cell to the left.

Edit necessary: remove 'a' between 'on' and 'any':
If focus is on any other cell, focus one cell to the left.

@annabbott
Copy link

annabbott commented Jul 17, 2018 •
edited
Loading

Design pattern > Keyboard Interaction For Data Grids > Control + Space > second bullet currently is:
If focus is on a call, selects the column that contains the focus.

Edit necessary: change 'call' to 'cell':
If focus is on a cell, selects the column that contains the focus.

@annabbott
Copy link

Design pattern > WAI-ARIA Roles, States, and Properties > fourth bullet > second sentence currently is:
Set to aria-expanded to false when the child rows are in a closed state and set to true when the child rows are in an open state.

Edit necessary: remove 'to' as second word in that sentence:
Set aria-expanded to false when the child rows are in a closed state and set to true when the child rows are in an open state.

@annabbott
Copy link

Design pattern > WAI-ARIA Roles, States, and Properties > fourth bullet > third sentence currently is:
End rows cannot have the aria-expanded attribute because, if they were to have it, they would be incorrectly described to assistive technologies as parent nodes.

What is an 'end row'? Is it a 'last row'? Or a 'bottom row' as mentioned previously? Needs clarification...

@annabbott
Copy link

Design pattern > WAI-ARIA Roles, States, and Properties > eleventh bullet currently is:
If the treegrid supports selection, when a cell or row is selected, the selected element has aria-selected set true.

Edit necessary: add 'to' before 'true':
If the treegrid supports selection, when a cell or row is selected, the selected element has aria-selected set to true.

@annabbott
Copy link

Design pattern > WAI-ARIA Roles, States, and Properties > twelfth bullet > first sentence currently is:
If the treegrid provides content editing functionality and contains cells that may have edit capabilities disabled in certain conditions, aria-readonly may be set true on cells where editing is disabled.

Edit necessary: add 'to' before 'true':
If the treegrid provides content editing functionality and contains cells that may have edit capabilities disabled in certain conditions, aria-readonly may be set to true on cells where editing is disabled.

@annabbott
Copy link

Design pattern > WAI-ARIA Roles, States, and Properties > twelfth bullet > second sentence currently is:
If edit functions are disabled for all cells, aria-readonly may be set true on the grid element.

Edit necessary: add 'to' before 'true':
If edit functions are disabled for all cells, aria-readonly may be set to true on the grid element.

@annabbott
Copy link

No further issues noted.

mcking65 added a commit that referenced this issue Jul 17, 2018
@mcking65
Treegrid Design Pattern: Editorial Corrections per Jul 16 Feedback in…
73eea9d 
… issue 91

Per feedback from #annabbott in issue #91, made multiple editorial revisions.
Made additional changes to phrasing to be more consistent with other patterns.
Removed first two sentences of first note in roles, states, and properties.
They stated that row and gridcell roles were not needed on treegrids built from HTML tables; that is currently not consistent with the ARIA in HTML spec.
@mcking65
Copy link
Contributor Author

Thank you @annabbott, I have made the corrections in commit 73eea9d.

@mcking65 mcking65 mentioned this issue Jul 20, 2018
Closed
mcking65 added a commit that referenced this issue Jul 20, 2018
@mcking65
Treegrid Pattern: Replace Note including development issue link with …
3aec48b 
…new note containing review issue link

Changed the introductory note in the treegrid pattern in aria-practices.html to replace the link to development issue #91 with a link to a new review issue 793.
Describe the pattern as new in APG 1.1 R2.
@mcking65
Copy link
Contributor Author

This issue is now complete and the pattern is ready for wide review. :) Closing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Pattern Page Related to a page documenting a Pattern
Projects
None yet
Milestone
1.1 APG Release 2
Development

No branches or pull requests
6 participants
@aleventhal @jongund @jnurthen @wendyabc @mcking65 @annabbott