Tree

[dubrod]

Accesible features integrated with the resource/elements/files trees

• [ ] Keyboard & Tab navigable
• [ ] Expand, Collapse
• [ ] Sort by (Outline/create steps to use Sort Index input field)
• [x] Search (your correct, searching the tree might not be a requirement with 2.3)
• [x] Refresh tree (this probably not needed since they can not drag n drop)
• [ ] When resource selected, Return keypress loads Edit page
• [ ] Create new resource button
• [ ] aria-expanded="true" is not working

Links I've found: https://github.com/cognovis/extjs/blob/master/www/ExtJS3/examples/tree/aria-tree.html

[rtripault]

As far as i understand :

• search (tree nodes filtering) is no more possible since 2.3
• sort by & refresh are about being able to display a tree contextual menu (current right click) and making the contextual menu accessible (ie. keyboard "browsable", not sure if some ARIA roles are relevant here -- mostly because i'm not yet used to ARIA roles, pointers would be appreciated)

[dubrod]

1. its 2 tabs to get to Resources then its down key twice to go down 1 link
2. (1) etc needs to be changed to ID 1 so it reads correctly
3. Can't tab from Resources to Elements or vice versa
4. there needs to be a brighter focus style on ALL selected elements
5. there needs to be a shortcut key to focus the resources first child LI to eliminate the "tab go around"
6. No ARIA tags

[rthrash]

I think Issue #7 addresses your point 6 above @dubrod … ditto for point 4 being addressed by Issue #9

Point 2 has to do with how the tree elements are read. I suspect we should switch to generated content for the IDs and probably introduce a "screen-only" class that works on screen readers.

[dubrod]

Hitting down key from Resources (3) did go to "Elements" but it did not open the list. So I could see where I was at.

[dubrod]

For compliance with Web Content Accessibility Guidelines (WCAG)

Keyboard accessibility of tablist/tab panels:

The tab panel is not keyboard accessible at all. The main tabs need to have tabindex="0" on the active tab and tabindex="-1" on the inactive tabs, and the JavaScript needs to toggle that value as users select different tabs. You also need to toggle aria-expanded="true" and aria-controls="the-id-of-the-tabpanel". See https://dequeuniversity.com/assets/js/aria/saveform/form2.html for an example.

Icon alternative text:

All of the icons (New document, New symlink, etc. and Trash) need alt text so screen readers know what to say. See "alt text for images and icons" in the uberbar above for possible techniques.

Button role for icons:

The icons (New document, New symlink, etc. and Trash) should be given role="button" or they should be enclosed in actual tags because they are perform application-type features, and a button is the appropriate semantic role to convey to screen reader users.

Keyboard-accessible tooltips for icon/buttons:

The tooltip should popup when the icons/buttons receive keyboard focus, and not just with mouseover events.

Keyboard accessibility of the button to collapse side bar:

The handle to collapse the entire side bar to the left needs to be keyboard accessible, and it needs to be a

or have role="button" and it must have a label ("collapse sidebar" for example) to convey to users its purpose.

Keyboard accessibility of tree view:

Users need to be able to access all items and functionality (refresh, add new __ here, etc.) in the tree view with the keyboard. It would be best to impelement an ARIA tree menu that allows navigation with the arrow key. You would tab into the tree object and then use the arrow keys to navigate within it, including expanding and collapsing nodes in the tree. Using the tab key would take you out of the tree, not navigate within it. Tree views are kind of complicated, but they can be made accessible. You would need to add ARIA attributes and toggle between various states such as aria-expanded="true". You would also need to make sure that the functionality of the expand/collapse icon/triangle is clear, and that it is separate from the functionality of the page title itself, which opens the page. See http://www.w3.org/TR/wai-aria/roles#tree http://accessibleculture.org/articles/2013/02/not-so-simple-aria-tree-views-and-screen-readers/

Keyboard accessibility of right-click menu in the tree view:

The functionality of the right-click menu needs to be available to keyboard users. All of the features are available other places, so this requirement is sort of satisfied already, but it would be best to make the right-click menu directly available to keyboard users, rather than make them go through the less efficient routes to the same features. You could implement a keyboard shortcut such as alt+enter on links in the menu to activate the right-click menu. To be effective, though, you would need to tell users that this keyboard shortcut exists, so you could add a tooltip to each link saying "Use alt + enter for contextual menu". You would need to ensure that screen readers also read this text. Particularly important is the ability to add new items (resources, elements, files) as children of the item that currently has the focus, since this is a very common task.

Keyboard focus management:

When you select a page to edit it, the focus initially goes to the pagetitle field, which seems logical. I like that. The problem is that the menu tree loads and refreshes, and as it does so, it eventually steals the keyboard focus away from that field and puts the focus on the current page in the tree view. This breaks the keyboard flow, and if you can't use a mouse, you have to tab, tab, tab, tab, tab, a lot of times to get back to where you were. Ensure that the tree view doesn't steal the focus.

See accessibility to-do list at https://dequeuniversity.com/modx-accessibility.html#tree-panel

[dubrod]

going to close this and make more specific issues. this is getting too broad