Community
Participate
Working Groups
we probably have accessibility work to do on the new orion tooltip. See also bug 371819 as well as the editor's tooltip, which sets some ARIA properties that we don't set yet in the new tooltip.
These are the tooltips (currently gray) that can be seen on the user menu, favorites star, all command links/buttons, etc.
In the 11/26 build I only see white-with-blue-outline tooltips that look like speech bubbles on the user menu and favorites star and some command buttons (but not on New/Action menu buttons). I assume I need to wait for a new build to get the new gray tooltips?
yes, the build containing tooltips hasn't been deployed yet. And to further confuse things, I'm working on bordering that will allow us to go back to white for now. I will ping here when the tooltips are in the deployed build.
Carolyn, the tooltips are now in the build. I changed them back to white (the gray was a workaround for having no borders in the first iteration).
Neither JAWS nor NVDA speak the new tooltips. They need 2 things, i.e. if there's an element with id="x" and the corresponding tooltip element id="xTip": 1) x needs aria-describedby="xTip" 2) xTip needs role="tooltip" FYI, the ARIA spec seems to suggest that the tooltip should pop up when the element (x) gets focus. I think that's a bit strange, and not strictly necessary. http://www.w3.org/WAI/PF/aria/roles#tooltip http://www.w3.org/WAI/PF/aria-practices/#tooltip However, I'd like to point out a few odd things in the area of tooltips on the main navigator page: https://orion.eclipse.org/navigate/table.html Let me know if these should be separate bug reports. 1) The action buttons on the left ("Clone Git Repository", "Sample HTML5 Site", etc) have identical tooltip text to the button text. This is an accessibility problem in that the text will likely be spoken twice. It's also a little odd, even for a sighted user. The only time it would be useful is for image-only buttons. 2) For those same 4 buttons, the most useful aria-describedby text would be the descriptive paragraph to the right of the button. For example, for the "Clone Git Repository" button, one might have HTML similar to the following: <tr> <td> <span id="CloneGitRepository" class="commandButton commandMargins taskTitle" tabindex="0" role="button" aria-describedby="CloneGitRepositoryDescription"> Clone Git Repository </span> </td> <td id="CloneGitRepositoryDescription" class="taskDescription"> Go to the Orion repositories page to provide a git repository URL. Once the repository is created, it will appear in the Navigator. </td> </tr> 3) Note that in the above code, I had to remove the spaces from the ids to make them useful. For example id="Clone Git Repository Description" does not work. (I say this because the ids look auto-generated from the button's element text, so probably the generator should automatically remove spaces). 4) Note that I gave the button a role="button". This is necessary because screen readers do not know what the semantics of a <span> is. (In fact, when I tab to those buttons, the screen readers think that an edit control has focus). 5) Is there a good reason why we use <span> for buttons instead of <button> ? Wouldn't we get a bunch of the semantics for free, and maybe not have to have as much javascript if we used the <button> element? They can be styled, just like any other html element. Just curious. 6) The "Add to Favorites" button has tooltip text of "Add to the Favorites list" and aria-label of "Add this page to the favorites list". When the button gets focus, the screen reader speaks the aria-label. Probably for image buttons the aria-label should be identical to the tooltip text. We will need to carefully test this case once we get tooltips working with screen readers to make sure that the tooltip (aria-describedby) and the label (aria-label) are not both spoken. 7) The "Search Orion Content" tooltip, i.e. the title ("Type a keyword or wild card to search in Orion Content") is spoken when the <input> element gets focus. Apparently some browsers do not expose the title attribute in an accessible way (which is odd, because it is the only one that my screen readers are speaking correctly <grin>). http://dev.w3.org/html5/spec/global-attributes.html#the-title-attribute Anyhow, I am only mentioning this because (once we get the Orion tooltip accessibility working) you might want to consider using an Orion tooltip instead of a title attribute. (There may be other places like this).
I have set the aria properties as described by Carolyn in comment 5. Commit is http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=7746fd6d93d9ca7fb4a08f137bba9c899356afea Carolyn, in the next build that is deployed (not the one today) can you recheck the tooltip speaking? All I did was verify that the properties are set in the DOM as suggested. As for the other suggestions (1-5) regarding the buttons on left side of navigator, those are probably disappearing in bug 387770, but I made a note in that bug to revisit your issues if we end up leaving the buttons there. For #6 we have removed the favorites star button so not an issue. I wasn't sure if #7 is an issue or not. If the title text is being spoken, is there a problem to fix? Or were you just pointing out a consistency issue? We should probably open a separate bug for this one. I'll keep this bug open pending your report on how tooltips behave now.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
