E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: Alexander Karelas
Date: Sat, May 05 2018 3:11AM
Subject: Tree role in a forum?
No previous message | Next message →

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

From: Jonathan Cohn
Date: Sat, May 05 2018 8:56AM
Subject: Re: Tree role in a forum?
← Previous message | Next message →

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

From: glen walker
Date: Sun, May 06 2018 8:55AM
Subject: Re: Tree role in a forum?
← Previous message | Next message →

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

From: Bryan Garaventa
Date: Mon, May 07 2018 10:53AM
Subject: Re: Tree role in a forum?
← Previous message | No next message

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 ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Sunday, May 06, 2018 7:55 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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
> >