Drupal 8 Content Experience: Accessibility Findings

dcmistry's picture

Drupal 8 Content Experience: Accessibility Findings


To conduct accessibility evaluation of Drupal 8 focussed on the content authoring experience (create content and edit content)


The study was conducted in July 2013 in two phases:
Phase 1: Evaluation with volunteer Drupal users with accessibility needs. The participants were given the testing script with scenario and were asked to report their feedback
Phase 2: Conduct 3-participant moderated usability study consistent with the testing script (mentioned above).


Phase 1: Participants were recruited by Thompson Terrill (terrill)
Phase 2: Participants were recruited by Dharmesh Mistry (dcmistry) and Chad Fenell (University of Minnesota)

Participant Profile

  • Participants who create/ edit content on a CMS or have a need to do so in the near future
  • Participants have a need to use accessibility features (keyboard, screen reader, zoom)
  • Participants have not used or seen Drupal 8/ Spark before


Overall, participants thought that the system was fairly accessibility while consuming content. However, they uncovered several issues while creating/ editing content. We have a lot of opportunity to improve the accessibility of Drupal 8.

  • “Fairly accessible for speech/ keyboard for content consumption.”
  • “I was able to complete tasks using only my keyboard”
  • “That was truly a pain free testing experience.” using Dragon NaturallySpeaking11 Professional

Owing to the nature of the study and the many metrics associated with it, the report is grouped by issues based on accessibility area.

Issues using Dragon

1. Exceptions where the element name needed to select an element was non obvious or confusing

For the most part, the participant was able to easily navigate the CMS using this sort of natural language interaction, but there were some exceptions where the element name needed to select an element was non obvious or confusing.
The shortcut button at the top of the Administrative Overlay is a nonstandard interface element, so it isn’t instantly obvious what one would say to activate it. Some digging around in the page source revealed that this icon stands in for an invisible span of text that says “add or remove icon,” so you would say “click add or remove icon” to select it. However, this is not the text that shows up as a tooltip when you hover over the icon, making speech interaction with it a bit obtuse.
The “X” icon in the top right of the overlay has no tooltip at all, which is even more challenging. The participant eventually discovered that its name was “close overlay,” but again it was only by looking through the page source. Users might be able to intuit this without a tooltip if they were aware of that this interface element is called an overlay, but there’s no guarantee since it’s never outwardly referred to as such.The participant tried saying “click close,” since “close” seemed like a likely name for the element, which kills the entire browser is there is no other match in the DOM.

2. Submenus were not responsive to voice control and had to be accessed using Dragon’s mousegrid system

The menu bar (home, menu, shortcut, evaluator) was responsive to voice "control" but the submenus were not and had to be accessed using Dragon's MouseGrid system.

3. Out of position elements in IE

When accessing the Administrative Overlay, by clicking on [Menu] and then any of the subordinate options, some strange layout element positioning occurs; things are out of position in IE. (It is fine in Firefox and Chrome)

The small iconic button to add or remove the shortcut (which in this case is a small circle with a minus sign in it) is shifted out of position. It should be directly adjacent to the title of the current overlay, as it is in the Chrome example image. But instead, it's down next to the breadcrumbs. This totally breaks the user's sense of what content that action is associated with.

Chrome: http://jrp3.net/warehouse/Overlay_Chrome.jpg
IE: http://jrp3.net/warehouse/Overlay_IE.jpg

The upward-shifting of the entire “overlay” div causes its topmost text to be occluded by the topnav. This makes navigating using the top-right tabs challenging for anyone, since they are hard to read, and especially for low-dexterity mouse users as it shrinks the targets by a little over 50%.
The “x” button in the top right of the overlay is completely nonfunctional in IE. I’m not sure whether this is related to the general layout issues or not.

Issues while using JAWS

1. Jaws did not indicate the state of the buttons

In order to tell whether something was in bold, italics, or underlined, the participant had to go to the toolbar every time to check the state of the button. The participant also noticed that formatting would change without notice. For example, the participant thought if he had turned italics off with control-I, only to find that, when he went to the toolbar, the italics button was still reported as being pressed. The participant tried using the combo box to change to full HTML, but, when he went past the combo box on my way to publish, he found that something else was selected.

2. JAWS having a hard time reading hidden content. It reads without spaces.

JAWS 14 is having a hard time understanding the Drupal 8 test site in Firefox. It mispronounces text as if it's ignoring all white space (e.g., "Skip to main content" is pronounced "Skiptomaincontent"). This issue was also found on NVDA and Window-Eyes.

One other participant noted that if we capitalized the first letter of each word, JAWS would read it correctly. This only seems to happen for content that is hidden from sighted users. Other content that is similarly mispronounced (the content in quotes is mispronounced):

Same page link "Skip to main content"
Heading level 3 "Toolbar Items" clickable
"undecipherable" horizontal clickable - this apparently is hidden content so I'm not sure what it's saying but it's clearly mispronounced
Heading level 3 "secondary menu"

Each of these items has class="visually-hidden", which has this style declaration:

.visually-hidden {
clip: rect(1px, 1px, 1px, 1px);
height: 1px;
overflow: hidden;
position: absolute !important;
width: 1px;

The skip link is actually contained within another hidden element, div#skip-link, which has this style declaration:

skip-link {

left: 50%;
margin-left: -5.25em;
margin-top: 0;
position: absolute;
width: auto;
z-index: 50; }

So that's hiding content using a different method. Maybe this combination of hiding content off screen then clipping it is causing the problem.

One participant figured this bug out. It's a problem in Firefox for all screen readers, confirmed using JAWS, Window-Eyes, and NVDA. The problem is this CSS, which is used to visibly hide content from sighted users while exposing it to screen readers:

.visually-hidden {
clip: rect(1px, 1px, 1px, 1px);
overflow: hidden;
position: absolute !important;
height: 1px;
width: 1px;

It turns out the problem is that last property, width:1px. That property is normally ok, but if content happens to also have the CSS word-wrap property set to "break-word" this causes a conflict. Firefox seems to strip out all the spaces between words, which is why screen readers' efforts to read the content sound like gobbledy-gook.

The participant submitted an issue to drupal.org and recommended that width:1 px be removed.

3. JAWS does not correctly announce a table in the rich text editor in Firefox.

It says "Not in a table", and announces cells as "blank" even if they contain content.

4. Say “Click to Add Content Link” instead of “Add Content Button”

Most visually impaired people refer to the item marked with add content as a link not a button. So when guiding visually impaired people through this interface it should say “Click on the Add Content Link" rather than “Add Content Button”

5. Labels missing from checkboxes on vertical tabs

In the vertical tabs on the right hand side of the add content screen, JAWS was unable to announce what the checkboxes were for - assumedly because there were no labels on the form elements.

6. Full HTML format did not allow or reveal any HTML code

Users who can’t use the WYSIWYG editor but would prefer to write the HTML code themselves were unable to do so since the full HTML format did not allow full HTML to be entered.

7. Tabs should allow formatting control inside the WYSIWYG editor

Other WYSIWYG editors allow tabs to control formatting. Users may find it confusing that CKeditor does not.

8. Careful use of headings missing

There was no H1 tag on the page. There were far too many H2 tags on the page, most of which were meaningless for navigation purposes.

9. Field Sets should be added for create content sidebar items (formerly vertical tabs)

using fieldsets to group form elements together is helpful because JAWS announces the legend before every form element within that fieldset, providing necessary context.

10. Add tab indexes on toggles

Some of the toggles had incorrect or missing tab indexes, this was confusing for users.

11. Links need to make sense out of context

Links that read “Article” are not useful (example is the create content page) since they don’t provide any indication that clicking on them would allow you to create an Article. “Add article” or “Create article” would be much better. A good rule of thumb is to “Use Natural language” in links so they make sense out of context.

12. Errors on the page are not visible to screen readers

If a Drupal form throws a validation error, it would be nice to inform people that has happened. Drupal’s errors are not clearly marked as errors with aria rules or other error tags, so people who can’t see will not know if a form has posted correctly or if an error has been thrown.

13. Landmarks or headings should be added to the create content page

Once someone has landed on the create content page, there are no landmarks and no headings, so users don’t know what to do. In one case, the user did not even know he was looking at a page with a form on it, that needed to be explained.

14. Progress indicators should be added for image/file uploads

When uploading an image the user was unaware when the image had completed the upload. Some kind of progress indicator or announcement when complete would have been appreciated.

15. Empty, required fields that state and invalid input are confusing

When JAWS read the title field it said “required, invalid input” which was distracting. Required would have been sufficient.

16. Message that suggests disabling overlay contains a link that is not ‘tabbable’

When users hear the message that suggests disabling the overlay to improve administration, the instinct is to hit TAB to find the link offered. When this link is embedded in a paragraph of text, (as it is) users can not tab to it and must listen for the text read allowed in order to locate the link.

17. Menu links that are toggles to other menus was confusing

Having a menu full of toggles was at first disorienting when users expected it to be navigation.

18. Link in navigation named ‘Menu’ is confusing

Why would you have to click on a link for the menu to get the menu? Isn’t this the menu?

19. Have meaningful “Read More” labels

The “Read more” links are going to be problematic for some screen reader users because they won’t make sense when read out of context. Screen reader users often navigate by structure so if they bring up a list of links on the page, they will encounter several “Read more” links that give no indication of what they are for.

20. Doesn’t tell the user that the link will open in a new window

Links which are set to open in a new window do not indicate that they are opening in a new window.
Here is a solution for Drupal 6 the participant made at NC State:

21. ARIA: ARIA navigation region should have aria-label attributes

The ARIA navigation regions should have aria-label attributes so the user knows what the function of each navigation region is.

22. Missing Alt-Text Images

Allows for image without alt text as some posted images have alt text omitted
Linked images contain null alt text. They do not give screen reader users an idea of what the links are for

23. Disorienting heading structures

The heading structure has an h2 before the h1. This can be disorienting to some screen reader users because for them, navigating the web is a very linear process.
Bug: URL of the content being populated incorrectly
If you click on "Content" that displays a large data table with each article in a row. The far right column of that table, with column header "Operations", contains two links, one to "Edit" and one to "Delete".

There seems to be a bug resulting in the URL for these links being populated incorrectly. Many of the links point redundantly to the same URL (nodes 19 and 25 are especially repeated a lot). As a result, if I click "Edit" to edit Terrill's article, I'm provided with a form to edit John's.

Issues while using keyboard only

1. Creating lists and headings and paragraphs are easy but don’t know how to fill in the table with the keyboard

Participant thought that creating a table is a breeze but he couldn’t figure out how to fill in the table with the keyboard. He could move between the headers he created but can't move from row to row.

If there is a way to edit html source of your own like or


that would be useful for those who just like to type.

2. No Keyboard focus when tabbing to “Save and Publish” button

When saving an article, the Save and Publish button does not show the keyboard focus when tabbing to it.

3. Can’t tab back

When creating a new article using only the keyboard, if the participant tabs past the end of the article editing area he cannot tab back into it. This is most likely because the editing window appears to be set up as a modal window without all of the necessary accessibility implementations. This behavior is actually seen on many types of editing pages, like
editing his profile. The participant was on Firefox on Windows and Mac.

4. I was not able to use tab to get to the rich text editor features

5. I was not able to get to the areas to change the url or the authored on information.

The participant was able to tab to "menu settings" when in edit or create mode. But the participant had to use mouse to change the url and delete those dates.

Issues with using Windows Eyes

1. Navigating to the toolbar is confusing

Navigating the toolbar was confusing because clicking on the menu - opens and closes the toolbar. It doesn’t guide the user that there is more to it. The particiipant finally understood that he had to click open the toolbar (says “toolbar tray tray open”) and then click down (to see content, structure, etc.)

2. Where should I go to create content?

Does not know where to go to create content - “Should I just click ‘Content’?” (P1)
Creating content experience is not optimal if you are browsing by landmarks (P1)
There are 2 landmarks - “Create article” (Heading 1) and “Add or remove shortcut”, and then close overlay, then 2 landmarks, then a heading 2 which says you are here.

3. Autocomplete is annoying and get’s in the way

Auto complete popup is “annoying” to Windows Eyes user because screen reader locks up and get’s confused as to what it should read - the content that is typed in or the autocomplete options?
“I would just take out the autocomplete; with a screen reader it is more frustrating than helpful. The screen reader doesn’t know what to do.” (P1)

4. Need clear instructions for creating “Summary” content

If you are on the hide summary button and push tab, you will notice the edit box that says “Summary hide Summary”. If you push tab again - it says nothing. It should say “Body of Summary”.

5. Accidental “Back” button and I lost my content

Accidentally hitting the back button while creating content makes you lose content.

6. Use landmarks wisely

There are 27 landmarks on create content page; navigating by landmarks makes it superfluous.
Having landmarks at the top and bottom confuses the users and they don’t know what is the landmark referring to. Participant suggested having landmarks at the top of the button. Banner landmark and nav landmark are next to each other. This confused the user and he wasn’t sure which was more important.

Issues for Low Vision Users

1. Need for better color contrast ration for low-vision users

Many areas on this site fail the color contrast test. (I used the Firefox plugin by Juicy Studio.) Some users with low-vision may have issues.
I also found in the admin overlay that the contrast wasn’t so great for the admin toolbar. Also, there isn’t a lot of differentiation between the color of the active and inactive links. Some users with low vision may not be able to tell the difference.

2. Fixed font-size is problematic to users with resizing needs

Some areas on the site use fixed font sizes. This may cause issues for users who need to resize the text. It also may cause sizes users have set in their browsers to be ignored.
The font-size overall really could be better. I find it a bit small, looking down at my laptop, and I have (corrected) 20/20 vision.

3. Light gray font difficult to read for low vision folks using magnification feature

Participants with low vision using just the magnification feature had difficulty reading the light gray font

4. Zoom causes the text wrap to the right side

When site is zoomed, some text wraps to the right size. Some folks who use magnification software may have issues finding where the text picks up again when the screen is magnified such that a lot of scrolling is required for them to view the entire area.

Other Issues


It was fatiguing to the participant to go to the top of the page to access the toolbar using a trackball mouse.
The participant also had a problem with the size of the buttons because she had to do more precise mouse movements to target the desired buttons/tabs/panels.

2. Spelling error on Accessibility help page

On the accessibility help page, it says "pages, press ALT + F10 to navigate to tab-list. Then move to next tab with TAB OR RIGTH ARROW.

3. Inconsistent font in Published Page vs. Text Editor

The font in the published page is a serif style font (i.e., Times New Roman), but the font used in the text editor is a sans serif style font (i.e., Calibri, Arial, Verdana). The sans serif font was easy to read while creating the article and editing. The serif font was not as easy to read on the published page.

4. Placement of Instructions should be above the field instead of below the field

The instructions for the input fields are below the boxes. If the instructions were above the input field, it might prevent people from inserting what they think is correct in the field before reading the instructions, then having to go back up to edit their response.

Special thank you to Jen Lampton, Jesse Beach, Terrill Thompson and Chad Fennell.


Fantastic work!

daniel.nitsche's picture

Is the intent to log these issues separately? And do you need assistance doing that?

Yes, the intent is to log

dcmistry's picture

Yes, the intent is to log these issues. But I would like to talk to the accessibility team before we start creating issues and understand how should we make this report actionable.

Dharmesh Mistry
UX Researcher | Acquia,Inc.

Next Steps

bowersox's picture

There is a lot of good info here. Some of the write-up provides enough details that we can turn pieces into tickets in the issue queue. Other parts of it don't have enough context for me to quite understand what is going wrong, or to evaluate what approach we should take to solve the issue. I have a few follow-up questions about portions of it.

@dcmistry, I'm wondering if you want us to "annotate" this document with follow-up suggestions or questions? Or do you want to hold a meeting or use some other format to triage these?

I'm happy to try this in whatever format works for you.

I'm going to go ahead and

bowersox's picture

I'm going to go ahead and create a spreadsheet (in Google Docs) where we can start to plan our follow-up on each issue from the findings. Based on today's scrum hangout conversation, we'll try scheduling a triage meeting to review this list and plan how we respond.

Triage meeting sounds like a

jessebeach's picture

Triage meeting sounds like a great next step!

Help Schedule the Triage meeting

Shyamala's picture

Please update availability at:

Link to event

See you all in a few hours. I

bowersox's picture

See you all in a few hours. I encourage everyone to read this report in advance of today's meeting. -Brandon

Versions used for testing

ycariveau's picture

What versions were used for testing above of Dragon and JAWS?


Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: