WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Tree role in a forum?

for

From: Jonathan Cohn
Date: May 5, 2018 8:56AM


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