New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JAWS (screen reader) doesn't read out the editable areas content #6002

Open
afercia opened this Issue Apr 5, 2018 · 9 comments

Comments

Projects
None yet
5 participants
@afercia
Contributor

afercia commented Apr 5, 2018

We're getting reports from accessibility testers that the content of the paragraphs etc. is not read out by JAWS or that weird things happen.

I've tested on Windows 10, IE11, and JAWS 2018 and was able to reproduce following a specific flow. Please try to follow the steps below to reproduce. See also the videorecording:
https://cloudup.com/cGohxttOPhN

In the first part of the video I'm moving through paragraphs using the Tab key and then:

  • use left and right arrow keys to read by character
  • use Ctrl + left and right arrow keys to read by word

JAWS reads out just "blank" or nothing.

Instead, in the second part of the video I'm moving through the paragraphs using the up/down arrow keys and JAWS reads the content by character and by word as expected.

Seems a pretty weird behavior and I have no idea why it's happening.

I guess we should investigate what changes in the blocks when moving via Tab or arrow keys. Any JS event triggering some behavior? Any attributes change? Any CSS change? (yes also CSS could play a role).

Any help from who knows the editable area internals would be greatly appreciated. /cc @aduth @youknowriad @iseulde

@aduth

This comment has been minimized.

Member

aduth commented Apr 5, 2018

For context, does JAWS tend to work generally well with a plain contenteditable element ?

@afercia

This comment has been minimized.

Contributor

afercia commented Apr 9, 2018

As far as I can tell JAWS works well with contenteditable. In this codepen: https://codepen.io/afercia/full/LdJgdK/ I've tested it a bit, including some complex HTML copied from WP and JAWS always reads out the content of the contenteditable element. So I'd tend to think it's not something related to HTML.

@afercia

This comment has been minimized.

Contributor

afercia commented May 5, 2018

To further clarify this issue, I'd recommend to have a look at the testing session by @sinabahram recorded by @joedolson at CSUN 2018, starting from minute 2:26 https://youtu.be/qpzyiL7n__0?t=2m26s and also published on https://make.wordpress.org/accessibility/2018/03/28/accessibility-of-gutenberg-the-state-of-play/

@sinabahram I'd greatly appreciate any help here, when you have a chance! Since you've tested at CSUN, the editable fields in the post content have been updated to use an ARIA role "textbox". For example the paragraph "block" should now be announced as edit text. Still to improve:

  • the labels (please ignore them for now)
  • aria-multiline should be set to true

However, JAWS still doesn't read the field value, or it does in a very inconsistent way.
Please also consider these editable fields are not real form fields. For example, a paragraph is a "p" element with a contenteditable attribute. This shouldn't make a difference, as the role textbox maps it to an edit text field. But still, there's something going on that prevents JAWS to correctly read the value.

@afercia

This comment has been minimized.

Contributor

afercia commented May 5, 2018

Testing a bit more with IE 11 and JAWS, I've noticed there's something related to focus, to reproduce:

  • tab into an existing paragraph
  • be sure JAWS switched to forms mode
  • try to read the paragraph content by character or by word
  • JAWS read out "blank"
  • now, press Alt + Tab to switch to any other application window that's currently opened (open one before the test if necessary)
  • press Alt + Tab to switch back to IE11
  • the caret should be in the same place as before, and now JAWS reads out everything correctly
@sinabahram

This comment has been minimized.

sinabahram commented May 5, 2018

@afercia

This comment has been minimized.

Contributor

afercia commented May 7, 2018

Yep works correctly in Chrome/Firefox, seems it's just an IE11 thing. Aside: one more reason why you don't hear the input value announced when you tab into it, is because the text within the field doesn't get selected. All browsers natively select the text within text fields. Instead, the Gutenberg fields behave more like textareas.

@tofumatt tofumatt self-assigned this Oct 4, 2018

@tofumatt

This comment has been minimized.

Member

tofumatt commented Nov 1, 2018

Is this also a problem in Edge or just in IE11? We definitely support IE 11 but doesn't Windows 10 ship with Edge these days anyway? I know users can opt to use IE, but I just want to know the size of users affected.

We tend to prioritise IE 11 fixes a bit less, in general.

@afercia

This comment has been minimized.

Contributor

afercia commented Nov 2, 2018

To my knowledge Edge doesn't work so well with JAWS and with other screen readers. Works a bit better with Narrator. You may want to have a look at these data about Screen Reader / Browser combinations. They're from October 2017 but the situation hasn't changed so much. https://webaim.org/projects/screenreadersurvey7/#browsercombos

@tofumatt

This comment has been minimized.

Member

tofumatt commented Nov 16, 2018

Because this isn't yet marked as in-progress I'm moving it out of the 5.0 RC milestone and into the follow-up fixes. Sorry for not getting to it in time.

@tofumatt tofumatt removed their assignment Nov 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment