1053279 - Make the treeherder front-end more accessible

Status: RESOLVED FIXED

(Tree Management :: Treeherder, defect, P3)

Description

[Marco Zehe (:MarcoZ)]

Right now, the front-end has a lot of clickables that have a) no label and b) no roles, states, and keyboard accessibility.
I wrote a while back how to make these clickables accessible:
http://www.marcozehe.de/2013/04/24/easy-aria-tip-6-making-clickables-accessible/

I request that these be followed to make treeherder accessible for the blind employees and volunteers. :) Please ping me for feedback.

Comment 1

[Ed Morley [:emorley]]

From IRC:
"keyboard focus visibility should also be ensured. Basically every :hover: should be accompanied by an :focus: in the CSS."

Comment 2

[Jonathan French (:jfrench)]

I will have a look this week, and see if I'm able to make at least some of the needed changes.

Comment 3

[Jonathan French (:jfrench)]

Marco is there any of this accessibility functionality missing in TBPL? Just so we have a baseline for comparison.

Comment 4

[Jonathan French (:jfrench)]

On a quick initial look it looks like the use of tabindex=0 in the markup on the job for tabbing through the jobs(which works), causes all of the processKeyboardEvents shortcuts to be ignored. i/j/n/k/p/u/[spacebar] for the various toggles, navigation to classified/unclassified failures, pinning, etc.

Comment 5

[Marco Zehe (:MarcoZ)]

(In reply to Jonathan French (:jfrench) from comment #3)
> Marco is there any of this accessibility functionality missing in TBPL? Just
> so we have a baseline for comparison.

TBPL is not particularly accessible, it is difficult to get at information. Since this is  a new development, I was hoping to be able to influence early on so we can get something better than TBPL.

If you're using j and k for navigation, making the items focusable via tabindex="-1" may be the right option, with only one tab stop at the container. That would then manage the actual focused items via aria-activedescendant, whose value always points at the actually focused item's ID. Not sure about the roles, what htese should be visually. Listbox/option? Or something similar to what Twitter does maybe. They have a pretty good implementation of such rich content, where j and k navigate by tweet, and tab allows to interact with each tweet more. They may be using a focus on the itemt hat has tabindex="-1", allowing the rest of the tab order to flow naturally.
Hope this helps!

Comment 6

[Jonathan Griffin (:jgriffin)]

Agreed this is needed, but can be done post-transition.

Comment 7

[Jonathan French (:jfrench)]

(In reply to Marco Zehe (:MarcoZ) from comment #5)
> (In reply to Jonathan French (:jfrench) from comment #3)
> 
> If you're using j and k for navigation, making the items focusable via
> tabindex="-1" may be the right option, with only one tab stop at the
> container. That would then manage the actual focused items via
> aria-activedescendant, whose value always points at the actually focused
> item's ID. Not sure about the roles, what htese should be visually.
> Listbox/option? Or something similar to what Twitter does maybe. They have a
> pretty good implementation of such rich content, where j and k navigate by
> tweet, and tab allows to interact with each tweet more. They may be using a
> focus on the itemt hat has tabindex="-1", allowing the rest of the tab order
> to flow naturally.
> Hope this helps!

Thanks Marco! I had a quick look at those properties yesterday, unfortunately I saw the same behavior, but I did not spend a large amount of time trying to sort out why. I am leaving this bug unassigned for now in case anyone wants to jump on it also.

Comment 8

[William Lachance (:wlach)]

I talked a bit with :davidb about this earlier this week.

As implied above, solving this bug properly involves figuring out a good keyboard navigation schema for navigating between pushes, their constituent jobs, and details of the particular jobs. However, adding the role/tabindex stuff to the spans is the first step and is pretty straightforward. I have a patch for that. 

I propose getting that landed now and then we can address the design questions behind making treeherder fully accessible later.

Comment 9

[William Lachance (:wlach)]

Attachment: Add role and tabindex for span buttons

Comment 10

[Treeherder GitHub Bugbot]

Commits pushed to master at https://github.com/mozilla/treeherder-ui

https://github.com/mozilla/treeherder-ui/commit/d54ae0143b1948e2521fc4ca3604503a320e49bc
Bug 1053279 - Add role and tabindex for span buttons

https://github.com/mozilla/treeherder-ui/commit/0150dc6a94af1589cc6b1e4c13fc42d5f42244e0
Merge pull request #174 from wlach/a11y

Bug 1053279 - Add role and tabindex for span buttons

Comment 11

[Ed Morley [:emorley]]

Reducing the number of P1 bugs at any one time, so there are a half dozen or so top issues on which efforts can be focused. This issue is incredible important, but there are ingestion/dataloss prevention bugs etc that need to be handled first before we call treeherder ready for non-sheriffs.

Comment 12

[Ed Morley [:emorley]]

See bug 654908 for more suggestions.

Comment 13

[Ed Morley [:emorley]]

How does Treeherder now compare to TBPL, accessibility wise? Is it a regression, on par, or better? I know we have a long way to go to make it ideal, I'm just wondering in the context of enf-of-lifing TBPL.

Comment 14

[William Lachance (:wlach)]

Marco, can you give feedback on how usable treeherder is with a screen reader vs. tbpl? I know neither is ideal, but it would be good to know if turning off tbpl is going to seriously impact people who use one (and whether there is any kind of stopgap fix we can make to make things halfway useable)

Comment 15

[Trevor Saunders (:tbsaunde)]

(In reply to Ed Morley [:edmorley] from comment #13)
> How does Treeherder now compare to TBPL, accessibility wise? Is it a
> regression, on par, or better? I know we have a long way to go to make it
> ideal, I'm just wondering in the context of enf-of-lifing TBPL.

I'd say its a rgression, while I can use it and get work done there are a few things that are a bit of a pain.

At least for me j/k and other keys that on tbpl just navigate between job links on treeherder seem to also activate find in page.

I'm also not aware of an easy way to get focus into the area that has log parsing and stuff for a job (on tbpl there is a heading for that section).

Comment 16

[William Lachance (:wlach)]

(In reply to Trevor Saunders (:tbsaunde) from comment #15)
> (In reply to Ed Morley [:edmorley] from comment #13)
> > How does Treeherder now compare to TBPL, accessibility wise? Is it a
> > regression, on par, or better? I know we have a long way to go to make it
> > ideal, I'm just wondering in the context of enf-of-lifing TBPL.
> 
> I'd say its a rgression, while I can use it and get work done there are a
> few things that are a bit of a pain.
> 
> At least for me j/k and other keys that on tbpl just navigate between job
> links on treeherder seem to also activate find in page.

This shouldn't be happening, it certainly doesn't for me. Could this be some kind of interaction between the screen reader and treeherder? I wouldn't think find-in-page should be activated any other way than the built-in firefox shortcut?

> I'm also not aware of an easy way to get focus into the area that has log
> parsing and stuff for a job (on tbpl there is a heading for that section).

Hmm, so inspecting the html it looks like we're using somewhat unsemantic naming for the bottom panel divs (i.e. bottom-left-top, bottom-left-bottom). Would giving the div's better id's (i.e. "job-actions", "job-details") help here? By "heading" in tbpl do you just mean the fact that the log parsing and job status is in something called "<div id='details'>"?

Comment 17

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to William Lachance (:wlach) from comment #16)
> (In reply to Trevor Saunders (:tbsaunde) from comment #15)
> > (In reply to Ed Morley [:edmorley] from comment #13)
> > > How does Treeherder now compare to TBPL, accessibility wise? Is it a
> > > regression, on par, or better? I know we have a long way to go to make it
> > > ideal, I'm just wondering in the context of enf-of-lifing TBPL.
> > 
> > I'd say its a rgression, while I can use it and get work done there are a
> > few things that are a bit of a pain.
> > 
> > At least for me j/k and other keys that on tbpl just navigate between job
> > links on treeherder seem to also activate find in page.
> 
> This shouldn't be happening, it certainly doesn't for me. Could this be some
> kind of interaction between the screen reader and treeherder? I wouldn't
> think find-in-page should be activated any other way than the built-in
> firefox shortcut?

Maybe a difference in the "accessibility.typeaheadfind" pref? If TBPL swallows j and k then presumeably typeaheadfind won't kick in...

Comment 18

[Marco Zehe (:MarcoZ)]

I'd say it's a regression, too. There are so many unsemantic elements like each of the build results in a job, the different jobs, the stuff at the top which only sems to be made up of CSS background imagery or some funky unicode symbols with no readable alternative text for the links, etc. Trevor and David also mentioned other issues above already.

Comment 19

[Ed Morley [:emorley]]

Marco/Trevor/David: Are you using TBPL or Treeherder at the moment? I'm just wondering if this blocks turning TBPL off; obviously we want to improve the Treeherder situation regardless.

Comment 20

[Marco Zehe (:MarcoZ)]

Muddling through with Treeherder. It's just a didferent kind of muddling through than with TBPL. So I'm fine either way.

Comment 21

[Trevor Saunders (:tbsaunde)]

(In reply to William Lachance (:wlach) from comment #16)
> (In reply to Trevor Saunders (:tbsaunde) from comment #15)
> > (In reply to Ed Morley [:edmorley] from comment #13)
> > > How does Treeherder now compare to TBPL, accessibility wise? Is it a
> > > regression, on par, or better? I know we have a long way to go to make it
> > > ideal, I'm just wondering in the context of enf-of-lifing TBPL.
> > 
> > I'd say its a rgression, while I can use it and get work done there are a
> > few things that are a bit of a pain.
> > 
> > At least for me j/k and other keys that on tbpl just navigate between job
> > links on treeherder seem to also activate find in page.
> 
> This shouldn't be happening, it certainly doesn't for me. Could this be some
> kind of interaction between the screen reader and treeherder? I wouldn't
> think find-in-page should be activated any other way than the built-in
> firefox shortcut?

it looks like I do have accessibility.typeaheadfind set to true, so maybe that's at fault.

> > I'm also not aware of an easy way to get focus into the area that has log
> > parsing and stuff for a job (on tbpl there is a heading for that section).
> 
> Hmm, so inspecting the html it looks like we're using somewhat unsemantic
> naming for the bottom panel divs (i.e. bottom-left-top, bottom-left-bottom).
> Would giving the div's better id's (i.e. "job-actions", "job-details") help
> here? By "heading" in tbpl do you just mean the fact that the log parsing
> and job status is in something called "<div id='details'>"?

I don't thing changing ids will effect anything, I was talking about the <job title> <test status> h3 element.

Comment 22

[Ed Morley [:emorley]]

Today's my last day before I'm on PTO, and then there are a couple of UK public holidays - so there is only actually 1 complete working day for me between now and 7th April. However after that I'd like to see what I can do to help here. I really know nothing at all about what makes the difference between a good screen reader experience and a bad one, so I'll have to do a bit of reading up on it which may take a while. If you have any low hanging fruit suggestions (beyond what's mentioned in the last comment or two) then that would give me a head start while I get my noob brain around this all.

Regarding this bug blocking bug 1059400 (which in turn blocks the tbpl-eol metabug), if people have already moved to treeherder, then the switching off of TBPL seems orthogonal to the problem of improving the Treeherder behaviour, so I'll remove the dependency.

Comment 23

[Treeherder GitHub Bugbot]

Commits pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/7afecdfebf0aeaef5f8bdfb9d53b7a786240fa58
Bug 1053279 - Add role and tabindex for span buttons

https://github.com/mozilla/treeherder/commit/ba5d5903079597017ee90c8035943447072c9da3
Merge pull request #174 from wlach/a11y

Bug 1053279 - Add role and tabindex for span buttons

Comment 24

[Ed Morley [:emorley]]

The PR in this bug landed, and the dep marks were fixed.

There's no doubt lots more that can be done, but it would be best to track in separate specific bugs rather than having multiple PRs in one bug. If there are other things we can do please do file bugs and we'll try our best to improve things :-)