WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Tree role in a forum?

for

From: Bryan Garaventa
Date: May 7, 2018 10:53AM

Hi,
ARIA Tree widgets do work accessibly, but they have to be programmed properly to do so.

E.G It's important to keep in mind that, though role=tree is a composite widget, role=treeitem is not.
http://www.w3.org/TR/wai-aria-1.1/#composite

Which means, the only focusable children allowed within role=treeitem nodes are those that match the required children list in role=tree
http://www.w3.org/TR/wai-aria-1.1/#tree
Specifically, role=group or role=treeitem, and no others.

The mappings for role=tree are also documented here
http://whatsock.com/training/matrices/#tree

If you want to program keypress navigation, this has to be done manually, or you need to implement a predesigned widget that does this automatically, like the following.
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Variation%20ARIA%20Tree%20With%20Right%20Click/demo.htm
Which includes letter navigation within the currently opened tree level, arrow key navigation, plus Shift+F10 or Applications key ARIA Menu support to match custom right-click menus.

It's important to note that any addition of structural content like headings, images, lists, tables, or any other type of active element that developers attempt to put inside of a role=treeitem container element will not be accessible at all across screen readers, because none of this content will be discoverable. The use of a Tree widget is meant to act as a basic arrow key navigation structure, which works similarly to a Listbox widget where the only focusable nodes allowed within it are those with role=option and no child active elements are allowed. This is why both of these widgets map to 'select'.

This construct has worked accessibly like this since 2012 and in JAWS versions going back to 11 and 12 in IE8 and FF.

One of the biggest issues with the perception that ARIA Trees are not accessible, has to do with badly programmed ARIA Trees that violate these basic concepts. Hopefully this helps a bit.

All the best,
Bryan


Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
<EMAIL REMOVED>
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen walker
Sent: Sunday, May 06, 2018 7:55 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Tree role in a forum?

I agree that the tree role should be used but the last time I used it, it wasn't very well supported. It's probably been a 1/2 year or more, though, since I used it so hopefully things have improved since then.

I would **not** rely on unread links to indicate unread messages, but I like that you want to use a built-in AT shortcut key to navigate to unread messages. Most forums and email apps use aria-labelledby that contains an ID that points to an "unread" label (in addition to other IDs to create a concatenated message), although creating concatenated messages is not typically a good solution if you have internationalization concerns because of grammar and syntax rules for some languages.

You could have a visually hidden heading, such as <h6> to make it very minor, for the "unread" state so that AT users could use the '6' key to quickly navigate to the unread messages.

Glen


On Sat, May 5, 2018 at 8:56 AM, Jonathan Cohn < <EMAIL REMOVED> > wrote:

> The tree role sounds like it would be useful. But you will need to
> implement your own keystrokes in the tree.
>
> https://www.w3.org/TR/wai-aria-1.1/#tree
> To be keyboard accessible <https://www.w3.org/TR/wai-
> aria-1.1/#dfn-keyboard-accessible>, authors SHOULD manage focus of
> descendants for all instances of this role <https://www.w3.org/TR/wai-
> aria-1.1/#dfn-role>, as described in Managing Focus <
> https://www.w3.org/TR/wai-aria-1.1/#managingfocus>.
>
> Also, if you look at ARIA 1.1 for the Composite role which is the
> parent role of Select which is a parent role of tree then it very
> specifically says you m should expect NVDA to be in Focus mode and
> JAWS to be in forms mode when Tree or any of its children have focus.
> Best wishes,
>
> Jonathan Cohn
>
>
>
> > On May 5, 2018, at 5:11 AM, Alexander Karelas
> > < <EMAIL REMOVED> >
> wrote:
> >
> > I develop this forum: https://forums.baza.gr/readmsg/92 in which (as
> > you might see) the titles of the messages in the thread form a
> > visual tree, similar to how threaded emails appear in Thunderbird,
> > or subject lines appear in USENET clients.
> >
> > Now I wonder if that visual tree should have a role="tree".
> >
> > I thought it would be a good idea, in order to allow screen-reader
> > users to navigate around the tree with standard keystrokes which
> > would avoid the confusion.
> >
> > But on the other hand, I see that the 'u' key in NVDA does nothing
> > when focus is inside the tree. I liked the fact that 'u' would go to
> > the next unread link (ie an unread message in the tree), since it
> > would allow the screen-reader user to not traverse the entire tree
> > to find a message that they haven't read already.
> >
> > So, does using role="tree" seem like a good idea to you in this case?
> >
> > Maybe I should code my own keyboard shortcut that will take the user
> > to the next unread message in the tree... something which would
> > require keeping track in the database of which messages they've read
> > already, since the browser won't report this information to
> > JavaScript for privacy reasons.
> >
> > What do you think? Any other advice?
> >
> > Thanks
> >
> > > > > > archives at http://webaim.org/discussion/archives
> > >
> > > archives at http://webaim.org/discussion/archives
> >