While trying to debug a WSOD in the installer of Drupal CMS, I've spent over the course of the last few days a decent amount of time in that very installer and realized that there are a few accessibility related problems along the way (plus one or two usability related. I’ve collected and summarized all the points in this issue, but feel free to chop up the issue into smaller segments:
1) The borders of the recipe checkboxes that are styled as buttons have a too low color contrast with 1.5:1 (#D4D4D8/#FFFFFF). The required minimum to meet SC1.4.11 would be at least 3:1
2) In the windows high contrast mode the outline for the expanded language options component has a solid unobscured outline, that way the expanded component is distinguishable from the background. here, in regular display mode, that border is not a solid one, instead a drop shadow is being used - the bottom border has a color contrast of 1.4:1 (#D6D9E0/#FFFFFF) for the darkest part of the drop shadow, the left and right are lighter and the upper border has no visible border at all. due to that drop shadow, the expanded component is not easily and clearly visually distinguishable from the background (SC1.4.11).
3) The color of the focus outline has only a color contrast of 2.2:1 (#7EB2FD/#FFFFFF) against the white background. Since the focus color is not provided by the user agent but is styled by Drupal CMS, to meet SC1.4.11, the focus color would need a color contrast of at least 3:1 against the white background to ensure the state is visible. On top of that there is also a usability related problem in the context of simultaneous contrast for the options in the language select component and the next button. due to the fact that the language names in the expanded language component have a blue text color and the focus outline is in a lighter blue as well, the focus outline isn't standing out as it would be desirable.
same for the primary button, although you have a offset of 2 pixels for the focus outline, it is still hard to recognize visually (personally i have a hard time to distinguish that the primary button is in focus here)
4) on the create your account page between the password field and the finish button is a focusable element that has no visible focus outline (SC2.4.7).
5) The icons (the globe and the caret) are not visible in the windows high contrast mode.
6) The outline for the expanded language options component has a solid unobscured outline, that way the expanded component is distinguishable from the background, only the color contrast narrowly misses the required 3:1 with 2.9:1 (#575757/#000000 - SC1.4.11)
7) The borders of the recipe checkboxes that are styled as buttons, and the next and skip this step button have a too low color contrast with 2.9:1 (#575757/#000000). The required minimum to meet SC1.4.11 would be at least 3:1. That applies to all the text fields on page 2 and 3 as well. And for the first page it has to be noted that visually there is no way to distinguish between the six recipe buttons and the two navigation buttons - they look uniform.
8) The skip to main content skip link has no visible focus outline and the recipe buttons have a close to invisible focus outline - there is some close to invisible aura (SC 2.4.7)
9) on the create your account page, between the password field and the finish button, is a focusable element that has no visible focus outline (SC2.4.7 - same as in regular mode).
At the moment the three pages in the installer are titled:
Just based on the page title it might be not necessarily clear for all three pages what the page specific context and the overall context actually is (SC2.4.2). On the first page additional recipes are getting selected, by reading just the page title which is identical with the page's h1 without the page’s additional help text, it is sort of hard to comprehend the actual purpose of the page. the other two page titles are sort of conversational, which is fine for forms on a page, but in the context of a page title i would prefer to stay descriptive and concise. and in regards of the overall context i wonder if it would make sense to use Drupal CMS Installer instead of Drupal CMS, otherwise after setting the site name on the second page i would expect that the second part of the page title after the | reflects that newly chosen site name?
In regard of language, the current implementation is in line with the wcag, so the following is more of a usability related consideration (but strictly speaking language can be considered a barrier as well). First it feels odd that the language select component is available for the first two steps and all of a sudden being unavailable for the last step. And even though you are selecting a language (set it to german), most of the content of the first page remains in english, only the two labels that are changed to german are the label for the language select and the next button. I've then checked https://localize.drupal.org/translate/languages/de/translate?project=dru... and realized that there is actually no project for Drupal CMS Installer yet? So the strings are not just untranslated yet, but there is actually missing an option to translate those strings in the first place?
Out of the box, no matter if the default language in your operating system is english or german like in my case, the default language in the installer is english. So if a person speaks no english at all, they first have to realize that the label in the upper right corner refers to an actual language selection - being presented with an interface in a language you do not understand at all might be confusing and or discouraging. We have discussed that problem in a previous ux meeting where we’ve reviewed the restyling of the installer for core #3085219-60: Installer is not very usable in Claro → . One of the suggestions we’ve proposed is reflected in the following issue: #3283369: Installer does not update language of "select language" step → - the idea simply was to use a pattern similar to Wordpress and or iOS/Android where the very first step is a select field where the user is able to pick their native language and all the interface copy in the following is then in the chosen language. (the other issue that came out of that meeting, which provides a new take about the general approach for the installer, was #3283371: Remove steps from installer → . the idea was to remove the steps from the installer in drupal core (which the installer for drupal cms is doing as well) by following a pattern introduced by gov.uk. at the moment it looks like the installer in drupal cms is less granular with fewer steps than the installer for core and while providing an additional option to select and apply recipes. so i wonder if it would make sense to make the installer for core and drupal cms more flexible and modular that it would be possible to add and remove certain steps - at the moment it looks like there is an installer for core and one installer for drupal cms now)
* We've discussed these points also at today a11y track meeting, and there was a consensus about the points in regard of regular and high contrast mode, and the page title. For the reference, attendees were @the_g_bomb and @itmaybejj
Active
Track: Installer
It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.
Makes Drupal easier to use. Preferred over UX, D7UX, etc.
Tried to edit the IS down to make it a bit easier to read.
@rkoller could you please create separate issues for the page title and language concerns? These don't really seem related. Also FWIW the title of the first installer page has changed to 'Get started' so I'm not sure if this addresses your concern at all.