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)
- 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.
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:
clip: rect(1px, 1px, 1px, 1px);
position: absolute !important;
The skip link is actually contained within another hidden element, div#skip-link, which has this style declaration:
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:
clip: rect(1px, 1px, 1px, 1px);
position: absolute !important;
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.
1. TRACKBALL MOUSE: Fatigue
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.