Draft tree view design pattern

[mcking65]

The tree view design pattern is at:
http://w3c.github.io/aria-practices/#TreeView

The guidance is complete. However, work to make it consistent with APG editorial guidelines is needed.
Specifically, the keyboard section format is not consistent with the guidelines.
The roles, states, and properties section includes "should" statements instead of present-tense statements.

Additionally, the description could be made easier to understand by defining terms before they are used.

Finally, some of the information in the table of examples should be moved into the example pages and the table can be changed to a list with simplified descriptions of what makes each example distinct.

As of November 30, 2016, The changes described below are merged into master and can be seen at:
http://w3c.github.io/aria-practices/#TreeView

Requested reviews

• Review by @annabbott
• Review by @accdc
• Review by @jnurthen

[mcking65]

Until we merge, the following changes to resolve this issue can be seen in the issue131 branch in rawgit.
And, you can compare to master in github.io.

The proposed resolution includes changes to the Tree View" design pattern section and adding a new sub section to the keyboard interface development section. The changes are as follows.

Treeview pattern description changes

1. Simplify and clarify definition, removing use of undefined terms.
2. Added child node, root node, and parent node to list of terms.
3. Described the difference between multi-select and single-select trees using the files system navigator introduced in the definition.

Keyboard subsection changes

Made the following revisions per the APG editorial guidelines.

1. Removed references to tab and described what happens when a tree receives focus.
2. Where two keys were described in a single bullet, separated them.
3. Start each bullet with a key name followed by a colon; removed the word key.
4. Fixed tense and removed "should" statements.
5. Removed use of the word visible to described a node revealed due to expansion since sometimes trees scroll and a node may be in an expanded branch but not visible.
6. For enter key, added option to select a node in a single-select tree where selection does not follow focus.
7. Addressed orientation; added statement at the beginning for vertical orientation, which is the default, and then added a note to address horizontal orientation.
8. Describe both acceptable models of multiple selection.
9. Add note about selection follows focus with a link to a new subsection of the keyboard interface design section.
10. Add note about separate controls for select all and unselect all.
11. Add note about aria-activedescendant.

Roles, states, and properties subsection changes

1. Fixed tense and removed "should" from the language.
2. Added statement that parent nodes contain or own a group.
3. Added statement that parent nodes have a label.
4. Added statement that tree elements have a label.
5. Added statement about aria-multiselectable and its default value of false.
6. Added statement about aria-orientation and its default value of vertical.
7. Added note about aria-owns.

Examples subsection changes

1. Replaced the table of examples with a list to match other sections.
2. Made more descriptive names for the example links.
3. Simplified the description of what each example demonstrates.

New subsection on selection follows focus

In the keyboard interface development section:

Added new section with id "kbd_selection_follows_focus"
and title "Deciding When to Make Selection Automatically Follow Focus"

Later, this section will include links to two two separate examples of tabs where one has selection follows focus and one does not.

[mcking65]

@jnurthen, @accdc, @annabbott
James, Bryan, and Ann,

Could you please review the above list of changes this week and provide feedback here in this issue?

[annabbott]

The first paragraph containing definition of treeview needs an edit:
have child items, and items that have children may be expanded or collapsed to show or hide the children. For example, in a file system navigator that uses a tree view to display folders and files, An <lower case the 'a' in 'an'> item representing a folder can be expanded to reveal the contents of the folder, which may be files, folders, or both.

[accdc]

The APG section for TreeView looks good to me.