Problem/Motivation

Drupal has several buttons or links where the text is visibly hidden and replaced with a small icons. This poses challenges to speech recognition users because they don't know what to say to trigger those commands. For buttons or links where the text is visible (e.g., "Home" or "Menu") speech rec users can simply say "Click Home" or "Click Menu". For icons without text, they can guess if the names of the controls are intuitive, but in Drupal's case they aren't.

Steps to reproduce

Proposed resolution

  • Add a title attribute to each control in order to reveal the text for that control to users when they hover. They'll need to use mouse commands at least once to discover the text, but subsequently they can use that text in a voice commands, which will be much more efficient.
  • Consider using more intuitive text. For example, rather than "Vertical orientation" and "Horizontal orientation" consider using "Move menu to left" and "Move menu to top"
  • Use larger icons so they're easier targets

Remaining tasks

Open up follow up tickets in quickedit and ckeditor4 modules
Reroll for toolbar
Review
Commit

User interface changes

NA

API changes

NA

Data model changes

NA

Release notes snippet

NA

Original Post

Problem/Motivation

Drupal 8 has several buttons or links where the text is visibly hidden and replaced with a small icons. This poses challenges to speech recognition users because they don't know what to say to trigger those commands. For buttons or links where the text is visible (e.g., "Home" or "Menu") speech rec users can simply say "Click Home" or "Click Menu". For icons without text, they can guess if the names of the controls are intuitive, but in Drupal's case they aren't.

Alternatively they can operate their mouse by voice (mouse left, mouse up, faster, faster, faster, stop, mouse down, mouse right, stop, click) but this is very cumbersome and if targets are small (which many are in Drupal) it's hard to stop at precisely the right position.

Proposed resolution

  • Add a title attribute to each control in order to reveal the text for that control to users when they hover. They'll need to use mouse commands at least once to discover the text, but subsequently they can use that text in a voice commands, which will be much more efficient.
  • Consider using more intuitive text. For example, rather than "Vertical orientation" and "Horizontal orientation" consider using "Move menu to left" and "Move menu to top"
  • Use larger icons so they're easier targets

Examples of icons that require fixing:

Top left corner, pencil icon: <button aria-pressed="false" role="button" class="icon icon-edit">Edit</button>

Secondary pencil icons such as:

<button type="button" class="trigger focusable" aria-pressed="false">open  configuration options</button>

And this one, next to search:

<button type="button" class="trigger focusable" aria-pressed="false">open Search configuration options</button>

The small "X" at top right corner of overlay:

<a aria-controls="overlay-content" role="button" class="overlay-close" href="#" id="overlay-close">
  <span class="visually-hidden">Close overlay</span>
</a>

The icons for swapping vertical and horizontal orientation of the secondary toolbar menu:

<button type="button" class="icon icon-toggle-vertical" value="vertical">Vertical orientation</button>

And:

<button type="button" class="icon icon-toggle-horizontal" value="horizontal">Horizontal  orientation</button>

The Small + or - icon (shortcut.png) that appears next to the main heading on various admin pages is unique in that it has accompanying text, which seems to be serving a function similar to having a title attribute:

<span class="icon">Add or remove shortcut</span>
<span class="text">Add to <em class="Placeholder">Default</em> shortcuts</span>

The text in the second span appears visible on hover. Why is this technique used for this icon only? I think it's ok, and speech rec users can use either text in their voice command (i.e., "Click add or remove shortcut" and "Click add to Default shortcuts" both work). However, it might be confusing if the text in the second span is always changing. Since that's the text that's visibly exposed users will discover that in one context, but if it changes dynamically the same command they've learned in one context might not work in another context.

Comments

bowersox’s picture

Feedback on the three proposed resolutions:

  • Add a title attribute: this sounds great. I think it's a no-brainer that doesn't have many down-sides. This should be easy and able to get into D8.
  • Consider using more intuitive text: this is a longer-term proposition, because changing the link text likely has implications for strings/translation.
  • Use larger icons: this would require collaboration with the UI/UX team.

It might be best to start with the first one and try to get that into D8.

@terrill, thanks for writing this up so well!

jessebeach’s picture

mgifford’s picture

@terrill - This has been amazing. We've really had very little input on how to make Drupal better for Dragon Naturally Speaking Users.

Thanks for adding these issues!

falcon03’s picture

Status: Needs work » Active

No patch to work on yet, so set status to active :-)

Let's make sure that adding the "title" attribute does not make the screen reader users experience worse saying both the invisible text and the title attribute value at the same time, making them hear the same thing two times.

mgifford’s picture

Issue tags: +tooltip

This gets back to #1919940: Build API to Replace Links using Title Attributes with Proper Accessible, Themable Tooltips, tooltips.

Providing a visual way to provide context in a way that doesn't mess up screen readers.

I thought the list of commands would be useful to see:
http://www.nuance.com/ucmprod/groups/dragon/@web/documents/collateral/nc...

Definitely want a solution that doesn't pit one user base against another.

mgifford’s picture

mgifford’s picture

Issue summary: View changes

Adding related links.

mgifford’s picture

Ok, I tried to add them above, but hopefully this works.

On Dragon KnowBrainer forum

Testing sandbox http://simplytest.me/project/drupal/8.x

mcjim’s picture

Does anyone know what JAWS needs for these buttons?
I've tried title, aria-label and an actual label tag with JAWS 15, but to no avail.

VoiceOver is happy with the element text, title or aria-label.

mcjim’s picture

Did some more testing: it may be my setup, I don't know, but the buttons are fine (as they are) with JAWS and FireFox or Chrome.

However, if I add a title attribute, that is read out in addition to the text within the element (JAWS with either FF or Chrome).
e.g. "Open my article configuration options button", immediately followed by whatever I put in the title, which isn't what we want to happen.

(JAWS and Internet Explorer I'm having problems with. It doesn't seem to like anything on the page. Could be my setup, I have no idea.
This is Windows 8.1, IE 11 and JAWS 15.)

mgifford’s picture

JAWS is highly configurable. Titles often present a problem as screen readers tend to read them out even if they are identical to the alternative text.

There are many times with accessibility issues where it is impossible to meet everyone's needs.

mgifford’s picture

StatusFileSize
new135.38 KB

I wanted to provide a good clear example an introduction of a button for evaluation for accessibility. Right now this is the button code for the pencil used for the inline editing:

<button class="trigger focusable visually-hidden" type="button" aria-pressed="false">Open configuration options</button>

I'm not sure if it is too small for people to focus on. I think that would depend on user testing.

The issue is whether to add a title attribute so that a Dragon user will know what to call that button after hovering over it. I just added this directly to the source using Firebug for this demo:

Example of button with title added to it

mgifford’s picture

Status: Active » Needs review
StatusFileSize
new1.89 KB

I do think we could really benefit from some Dragon users... But here's a patch to see if we're leaning the right direction.

mgifford queued 13: Dragon-2046529-13.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 13: Dragon-2046529-13.patch, failed testing.

mgifford’s picture

Status: Needs work » Needs review
StatusFileSize
new1.89 KB

Rerolling the above patch.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andrewmacpherson’s picture

A relevant post about how WordPress are approaching Dragon etc, including responses form users testing it.

https://make.wordpress.org/accessibility/2016/05/13/20th-wordpress-acces...

mgifford’s picture

It's great that WP is taking this on. Lots to learn from this approach.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Version: 9.4.x-dev » 10.1.x-dev
Status: Needs review » Needs work
Issue tags: +Needs issue summary update

Ckeditor and quickedit have been removed in D10 so separate tickets should be opened in the contrib project for those.

Then this ticket can be rerolled for just toolbar. Also should include IS update

smustgrave’s picture

Issue summary: View changes
Status: Needs work » Needs review
Issue tags: -Needs issue summary update
StatusFileSize
new1.98 KB
new561 bytes
gaurav-mathur’s picture

Applied patch #31 successfully on drupal version 10.1.x and working fine.
Thank you

mgifford’s picture

Issue tags: +wcag412

Adding WCAG 4.1.2

duaelfr’s picture

Status: Needs review » Reviewed & tested by the community

Looks good. Fixes the issue.
Given the length of the remaining fix, I don't have much more to say ;)
Thansk!

lauriii’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs accessibility review

This was proposed almost 10 years ago. I think it would be great if someone could check if this is still what we should be doing. 😇

lauriii’s picture

Wait, I looked at the patch and I'm confused. Maybe what we actually need is a title + brief issue summary update? It totally makes sense that the button should have text, but that's not what I was expecting based on the title. 🤯

smustgrave’s picture

Status: Needs review » Needs work

Think this does need some more thinking out.

At first I was actually wonder if it's needed now. I see the button has text in it so it should be fine.

But I installed the examples module which adds a tab to the toolbar. And that has an empty button for switching between vertical/horizontal..

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.