Repository navigation
Can't access player controls with JAWS cursor #81
Description
This may or may not be a problem since the player controls work well with JAWS virtual cursor, but it raises some interesting questions:
- What type of elements does the JAWS cursor recognize?
- What is unique about Able Player controls that prevents JAWS cursor from recognizing them?
- How can the controls be coded differently in order to address this problem (without a complete overhaul)?
This was tested with JAWS 15 in IE11, with iconType = "font". Need to test with iconType= "image" as well.
Activity
terrill commentedon Sep 28, 2014
Further tests show that the JAWS cursor is unable to read a
<button>unless it has text content. It doesn't read the aria-label attribute, title attribute, a nested image with alt text, or visibly hidden (clipped) text inside the<button>. This was tested with JAWS 15 and 16 beta in both IE11 and Firefox.http://terrillthompson.com/tests/jaws-cursor.html
In Able Player, this means the JAWS cursor doesn't recognize any of the controls, regardless of whether this.iconType='font' or 'image'. Since the player controls are accessible for all other screen readers, including JAWS in virtual mode, I'm actually ok with this, and marking this issue closed.
kensgists commentedon Feb 4, 2015
Should add aria-label along with title to the buttons, keeping the text for both aria-label and title the same.
Adding aria-label makes the button text read in Firefox with JAWS while in cursor mode (it was always read in virtual mode, when tabbing). With just the title, buttons announce only "button."
I have gotten at least two complaints about this issue and have tested with icon fonts when using aria-label and it seems to resolve the issue. For example, see left-align, center align, etc. buttons here: http://getbootstrap.com/components/#glyphicons-examples
terrill commentedon Feb 4, 2015
I don't remember the details now but I know aria-label was removed intentionally due to undesirable side-effects (most likely some screen reader/browser combination was resulting in redundant label announcement). I think we should develop some test cases using various methods of coding the player buttons, then test them all using various screen reader/version/browser combinations and document the findings in the project wiki.
One thing I feel strongly about is that title must remain, since it makes the label discoverable for speech recognition users. So the question is: Do we want to supplement title with aria-label, visibly hidden text, or nothing?
kensgists commentedon Feb 4, 2015
Sounds like a plan. I can do this tonight. Would icon fonts (as we are already using) and image buttons with/without alt be adequate? Can set up a variety of title +/- aria-label tests.
terrill commentedon Feb 4, 2015
Yes, I think just testing our two modes, triggered with data-icon-type="font" or data-icon-type="image". We should actually test without title too. If it works better to have aria-label without title we could always create our own visible tooltip using the aria-label value.
kensgists commentedon Feb 4, 2015
I'll have a page for review tomorrow. Was thinking similarly about tooltip, since the only browser that shows title on keyboard focus now is IE.
kensgists commentedon Feb 5, 2015
I have a page with various implementations and results, here: https://dl.dropboxusercontent.com/u/4904309/experiments/buttons.html
The glyph implementation in Test 3 and the image implementation in Test 7 give the most satisfactory results, in my opinion.
terrill commentedon Feb 16, 2015
@kensgists also created this test page for testing with speech recognition:
https://dl.dropboxusercontent.com/u/4904309/experiments/sr-button-test.html
Based on our tests, the following markup results in the most consistently accessible experience across AT/browser combinations:
The above has been implemented in ac74ea7
Since the button no longer has a title attribute, also added functionality to render tooltips using aria-label. This is better than relying on browsers' native support of title anyway since most browsers don't display a tooltip on focus. Added this in 01cefa1