Quicktags: use aria-label to improve accessibility

[afercia]

Reported in the last accessibility testers group testing session, see: ​https://make.wordpress.org/accessibility/2015/03/03/test-chat-summary-march-2/

In the "quicktags" buttons in the text editor there's nothing that can be read out by screen readers but their "value" attribute. Screen readers will read out:

b button
i button
link button
b-quote button
del button
ins button
img button
ul button
ol button
li button
code button
more button
close tags button Close all open tags

The proposed patch adds aria-label attributes, this way buttons will be read out:

Bold button
Italic button
Link button
Blockquote button
Deleted text (strikethrough) button
Added text button
Image button
Bulleted list button
Numbered list button
List item button
Code button
Insert Read More tag button
Close all open tags button

Also, removes the title attribute on the "Close tags" button.

Please notice there are some outstanding issues:

"del" and "ins" tags are used in a not-semantic way: they're meant to mark up additions and deletions (like in document revisions) and instead they're used as "strikethrough" and "highlight" text.

As far as I can see, TinyMCE doesn't have "ins".

Moreover, while TinyMCE adds just the "del" tag, quicktags.js add also the "datetime" attribute which is perfectly OK and enforces the semantic meaning of the tags so they would really mean "deleted text, added text and when they were deleted/added" but then they're used for visual purposes.

TinyMCE:
<del>text</del> 

quicktags:
<del datetime="2015-03-04T16:19:27+00:00">text</del>
<ins datetime="2015-03-04T16:19:27+00:00">text</ins>

Thus, there's inconsistency with TinyMCE and I'm not sure which label text would be more appropriate. Open to suggestions, there should be parity with TinyMCE.

Worth noting that using "strong" and "em" for "bold" and "italic" is not perfectly semantic too.

Finally, I'm not sure the current text for the "Close tag" label (formerly the title attribute) is appropriate for what that button really does:
Close all open tags
maybe should be
Close last inserted open tag ?

Any thoughts more than welcome.

[joedolson]

Honestly, I'd like to see <del> and <ins> removed from both quicktags and TinyMCE by default. This probably needs some user feedback, but my gut feeling is that most users never use them at all, and most of those who do use them incorrectly. I'd rather have <s> for strikethrough, and leave the semantic use cases for more knowledgeable users.

If I'm wrong, and these tags are actually used (and used correctly), I'd obviously change my view, but I don't really think that they belong in the default set of editing tools.

[DrewAPicture]

Replying to joedolson:

Honestly, I'd like to see <del> and <ins> removed from both quicktags and TinyMCE by default. This probably needs some user feedback, but my gut feeling is that most users never use them at all, and most of those who do use them incorrectly. I'd rather have <s> for strikethrough, and leave the semantic use cases for more knowledgeable users.

If I'm wrong, and these tags are actually used (and used correctly), I'd obviously change my view, but I don't really think that they belong in the default set of editing tools.

I wonder if we could get any usage stats from wp.com, though that kind of falls of scope of this ticket. For now, I'd encourage adding the aria-label attributes to everything we've got now.

[rianrietveld]

Test results from the wapa11y test team:

@gab-nino: VoiceOver, Safari 8.0.3 on Mac. Chrome (41) for Mac. Chrome (39), Windows XP and NVDA.
All the “quicktags” for the text markup were properly labeled, understandable and complete in both NVDA and Safari.
About the Div row-actions invisible with NVDA: When using NVDA, the row-actions menu was hidden all the time. The only time it was visible was when the submitted-on link had the focus. So to perform the test I had to cheat and use the mouse to click on the edit comment link.

Michelle de Young: Win8.1/FF/NVDA
Virtual mode – Was unable to access the action links in the Comments section unless the spacebar is used. User does not know they need to do that. Sometimes the links list would appear and disappear quickly when the spacebar was pressed.
Forms mode – Was able to access the action links, ‘Edit section’, ‘Quick Edit’ section, and the ‘Quick tags’ in the rich text editor.

Win7/IE/JAWS
Virtual mode – Action links in the Comments section are not displayed, but they are voiced by the screen reader and user is able to access them. ‘Enter’ or ‘Spacebar’ opens the editor.
Forms mode - Was able to access the action links, ‘Edit section’, ‘Quick Edit’ section, and the ‘Quick tags’ in the rich text editor.

Win8.1/Chrome/Chromevox
Virtual mode – When arrowing to the Comments section in the table and the Submitted on date is reached, the list of action links become displayed, but when the user arrows past the date the list of links disappears and is never read by the screen reader or available to the user. Could not access the rich text editor to test the “Quick tags.”
Forms mode - When tabbing the user can tab to the action links in the Comments section and access them. I did notice that if ‘Quick Edit’ is selected the user is jumped out of the table and focus is taken to the Search box. Could not access the rich text editor to test the “Quick tags.”

Suggestion: Perhaps add an aria-polite to the ‘Quick Edit’ section that’s toggles it’s display. User is unaware that something has changed on the page, and that their cursor focus was dropped into the rich text editor.

I can move to the 'Edit' link and use [Enter] to open the the Edit screen. I thought it might be only occurring with internal links, but the 'Publish Immediately Edit' link is operational. This leads me to think perhaps something is off with the js for the aria status for hidden or visible for the items in the Post section. For the 'Quick Edit' and 'Reply' Link in the Comments section, I wonder if there is a similar issue.
When the internal links are selected the user focus should move to what was opened on that current screen. I'm not sure if aria-controls or aria-owns would be of benefit in this scenario.

​http://www.w3.org/TR/wai-aria/states_and_properties#aria-controls
​http://www.w3.org/TR/wai-aria/states_and_properties#aria-owns

Wish I knew if it's a ChromeVox bug or not.

Kim van Iersel: JAWS 15
No problems found, everything is neatly labelled

Ruud van den Bercken:In IE11/supernova 14.04
I am a somewhat experienced user and never thought that unlabled buttons would not be clear for dummies/beginners....
It never bothered me. In ie11/supernova 14.04 the labels are clear now.

Note from Rian: Supernova is a screen reader used in Europe.

@Badeyes: JAWS 14.5 IE 11
As a coder I dont use the bold, link tabs so I find it tedious having to tab through them just to get to the edit field, wouldn't it make more sense to have it closed by default and if someone wants to use it they can do so, at the very least have the close tab button at the top not at the bottom.
Also, even if I wanted to use it how is a screen reader user supposed to insert any of these things in the right place, the minute I go out of the edit screen I dont have a clue what is highlighted, or where the cursor is.

John Sexton: Supernova V14 + IE11 + Win7
Tabbing through the buttons on a new comment reads out the labels but says "button" twice.
Using the cursors to navigate (using auto-dolphin-cursor), gives the same result accept the colour button is treated as two separate buttons. The first reads out as colour button and the other as just button. Interestingly this is the same in either direction.

The quick edit menu is not obvious in supernova, to activate you have to use cursor navigation and press space while over the comment text. Then use either cursors or tabs to locate the quick nav menu.
The buttons on the quick edit screen are read out as:
when tabbing: bold button, italic button ...
when using cursors: bold b button, italic I button ...

Testing NVDA + IE11 + Win7
Activating the quick edit is not obvious, have to press space while cursor focus is over the comment, then press tab to find the link.
The process is first use cursors to locate the comment text, press space while focused over comment text, then tab to quick edit and press enter.
If just using tabbing it skips over the comment text and if just using cursors, it skips over the quick nav menu.
tabbing through the buttons reads out bold button, italic button ... however when cursoring through it reads them all as a single sequence.

Possible improvements may be to add tabindex=0 to the comment text and move focus to the first item of the quick nav menu on users click (pressing space).
Or adding a dedicated quick nav button, that toggles view of the quick nav menu for a given comment.

Unknown tester: Jaws 13, Firefox, Win7 64-bit
Comment buttons read well. Noticed, however, some blank links. On investigation:
right before posts, there is a link that's not read, but, when tested w/Jaws ReadCharacter function, is translated to character 61705. A blank link prior to comments is translated as character 61697. I rather suspect these might be genericons. I posted to the A11Y team earlier that these are becoming problematic, as, by default, they're not read by screenreaders. Perhaps they're just arrows or something & have no significance, but it is disconcerting to have blank links. On the other hand, they might serve to collapse the menu items, which really might be problematic.

Tobias Clemens Häcker: ChromeVox, Browser Chrome, Windows7
I had a hard time understanding the voice output of ChromeVox when using bold or italic on the text selection with ctrl + i/b keyboard shortcuts. I'm pretty certain that the word bold was not part of the audio output.

When using alt+F10 to access the buttons directly most of them have the same voice output and results of actions (for example: selected text is now bold) are not output.

When testing with with the old nightly version I could not notice any difference. This might be due to shortcomings of ChromeVox however.

Remarks by Rian:
If this patch works depends on the browser/screen reader combination used. And also on the skills of the user.
It's hard to get it to work and make it usable and understandable. This definitely needs more work.
But the patch is an improvement for most screen reader users and it doesn't break anything.

[afercia]

When buttons are in a "close tag" status, their ARIA label should change in something like, for example: "Close bold tag". Realized this can be done with custom data attributes in order to provide fully translatable strings.
Patch incoming, need to test it a bit more, will upload tomorrow.

[afercia]

Refreshed patch to have proper labels when buttons are in "close tag" status. Actually there's no need to output custom data attributes, just have the new strings in the button object.
Tested in latest Firefox, latest Chrome and IE 8.

For reference, here's the list of the new aria-label strings plus some strings I'd propose to change to better reflect what the related button does. Any thoughts and suggestions for better text more than welcome:

'strong'          => 'Bold'
'strongClose'     => 'Close bold tag'
'emphasized'      => 'Italic'
'emphasizedClose' => 'Close italic tag'
'link'            => 'Insert link'
'blockquote'      => 'Blockquote'
'blockquoteClose' => 'Close blockquote tag'
'deletion'        => 'Deleted text (strikethrough)'
'deletionClose'   => 'Close deleted text tag'
'insertion'       => 'Added text'
'insertionClose'  => 'Close added text tag'
'image'           => 'Insert image'
'bulllist'        => 'Bulleted list'
'bulllistClose'   => 'Close bulleted list tag'
'numlist'         => 'Numbered list'
'numlistClose'    => 'Close numbered list tag'
'listitem'        => 'List item'
'listitemClose'   => 'Close list item tag'
'code'            => 'Code'
'codeClose'       => 'Close code tag'

Will create new tickets for the outstanding issues (<del>, <ins>, etc.).

[afercia]

Adds labels for the buttons "close" status.

[afercia]

Tested again in latest Firefox+NVDA and Chrome+ChromeVox, all works nicely. I'd say the only thing left here is to make a decision about the "del" and "ins" buttons label text:

'deletion'        => 'Deleted text (strikethrough)'
'deletionClose'   => 'Close deleted text tag'
'insertion'       => 'Added text'
'insertionClose'  => 'Close added text tag'

Other than that, I'd say the patch is ready for commit consideration.

[azaozz]

I'm actually not sure if it is a good idea to add "plain language" descriptions to these buttons.

The Text editor and the Quicktags toolbar are targeted only at people that have some understanding of HTML. It is not necessary to use the Quicktags toolbar to enter these tags, it just makes it a bit faster/easier.

As far as I see from the tests, the Quicktags buttons are working pretty well at the moment. Thinking that it is better to keep the audible button descriptions to the HTML tags they insert, i.e. b and /b, etc. That way there will not be any confusion of what the buttons do or are supposed to do.

[afercia]

Replying to azaozz:

As far as I see from the tests, the Quicktags buttons are working pretty well at the moment.

Hi @azaozz, actually the tests were run with the patch applied :) that's why users generally said the labels were OK and perfectly understandable and they instead focused on other issues.

[azaozz]

Replying to afercia:

Ah, I see. Were there any tests without the patch?

There are two reasons I think this can be confusing:

• The buttons behave differently depending on whether something is selected in the textarea. If there is a selection it is wrapped with the tag, if not, only the opening tag is inserted.
• As I mentioned above this toolbar is not necessary to use and is targeted at people with some understanding of HTML. Wouldn't it be clearer for the screen readers to announce the actual HTML tags instead of "plain language" descriptions of the tags? I.e. the button "del" will have ariaLabel="<del>", etc.

[afercia]

Replying to azaozz:

Were there any tests without the patch?

I think yes, we should have something would need @rianrietveld help to retrieve some report.

The buttons behave differently depending on whether something is selected in the textarea.

Yup I know. The patch tries to take care of this. It's more confusing to hear bee or slash bee IMHO.

As I mentioned above this toolbar is not necessary to use and is targeted at people with some understanding of HTML. Wouldn't it be clearer for the screen readers to announce the actual HTML tags instead of "plain language" descriptions of the tags?

To my understanding, and from the feedback during the test, many screen reader users often switch to "HTML" mode because TinyMCE is too difficult to use. They're not necessarily technical but would need some basic formatting.

[azaozz]

Replying to afercia:

...It's more confusing to hear bee or slash bee IMHO.

Yeah, I was proposing to change that to the whole HTML tag, so something like 'less-than slash bee greater-than', etc.

Looking at 31522.2.patch: we can't move around the args of "publicly accessible" functions and methods. Will break plugins :)

Can you check if 31522.3.patch works as expected? It adds an object instead of two new args. That can eventually be reused to add more attributes if needed.

[afercia]

Ops, yeah the order of arguments! My bad :( Will ask the accessibility team if there's any chance to have some users feedback about the labeling. I got your point, they're HTML tags "snippets" (when no selection) but more a "make this bold" thing when there is a selection. So when there is a selection I'm not sure about using something like 'less-than slash bee greater-than'. Tricky to solve.

Can you check if 31522.3.patch works as expected?

Works like a charm :)

Worth considering some more things to improve the quick tags experience, will open new tickets if they don't have one already:

• was thinking to group the buttons in a fieldset and use a legend to give users a short description
• the help tab should have some description or at least a direct link to the codex page ​https://codex.wordpress.org/Posts_Add_New_Screen#Visual_Versus_Text_Editor Worth noting that page should be updated, still refers to accesskey attributes (removed in 29878) not to mention I really don't know what an "accesskey JavaScript attribute" is. Well, typos happen :) will update.
• wondering if we can have the link to the codex page inside the legend
• #31661 and @Cheffheid effort to improve text selection with the keyboard
• our discussion a while ago about having parity with TinyMCE: the toolbar should be initially out of tab order then Alt+F10 should focus the toolbar and bring the buttons back in the tab order

[azaozz]

In 32883:

Editor: add ARIA labels to the Quicktags buttons to improve accessibility.
Props afercia, azaozz. Fixes #31522.