Problem/Motivation
As part of #2809635: Create experimental installation profile we intend to add an experimental profile for Drupal 8.
This profile will be different to the other profiles in core in so far as its more of a finished product than a starter kit.
Or to use the Lego analogy, its a Police Station set, instead of a bucket of bricks.
At present the installer's 'select profile' screen doesn't really facilitate communicating this type of information.
Proposed resolution
Redesign the 'select profile' screen to include additional functionality - possibly including
- The ability for profiles to provide a screenshot/thumbnail/logo - like themes can
- A default logo - for profiles that don't provide one - my thinking is this should look like the module icon we have in the toolbar, i.e. a 'generic starter kit' building block, but I'm not a designer
- Grouping into 'starter kits' and 'fully featured products' (exact naming to be confirmed)
- A treatment for experimental profiles to indicate they aren't yet stable - this might include their alpha/beta status or might just be a label 'Experimental'
Remaining tasks
Come up with the design.
Implementation is a separate issue.
User interface changes
New installer screen design.
API changes
Possibly new keys available in profile's .info.yml (not in this issue).
Data model changes
None
Comment | File | Size | Author |
---|---|---|---|
#53 | install_error.png | 535.49 KB | kreynen |
#53 | diff_of_settings_commit.png | 88.02 KB | kreynen |
#40 | umami-profile-selection-screen.png | 528.92 KB | yoroy |
#39 | installation-profile-demo-selected.png | 251.04 KB | ckrina |
#39 | installation-profile-demo.png | 222.58 KB | ckrina |
Comments
Comment #2
tkoleary CreditAttribution: tkoleary at Acquia commentedComment #3
tkoleary CreditAttribution: tkoleary at Acquia commentedHere's my first pass. Added some copy too.
Comment #4
larowlan<3 looking good
Do you think we should separate standard and minimal into a 'build your own'/'building blocks' group and the farmers market one into a 'full featured' group? that would allow future profiles. Or should we wait for those profiles to exist first?
Comment #5
tkoleary CreditAttribution: tkoleary at Acquia commented@larowlan
I'd keep it simple for now.
Comment #6
tkoleary CreditAttribution: tkoleary at Acquia commentedComment #7
lauriiiI like the idea of adding more information about installation profiles to the installer so that the user is more likely to choose the right installation profile.
I was wondering if we should use the shadow that is used in many parts in the Seven style guide. I'm also slightly concerned if it's obvious for users what is the clickable area. Seven style guide doesn't also have any reference for the blue side border that is used on the design. Besides that, the design looks great for me!
Comment #8
ckrinaGreat work! I also think adding more info to each installation profile is really useful.
But I am concerned about the Experimental warning: I think it is really well integrated, but maybe it makes it difficult for the user to realize about it. Maybe looking for a solution that doesn't scares but that implies some kind of "warning" message could be useful.
Comment #9
tkoleary CreditAttribution: tkoleary at Acquia commented@ckrina
That's a really good point. What if we made it red?
Comment #10
tkoleary CreditAttribution: tkoleary at Acquia commented@lauriii
There is some precedent for the lefthand border as selected or active indicator in nav tabs. It's not in the guide but it should be.
Comment #11
tkoleary CreditAttribution: tkoleary at Acquia commented@laurii
Added to seven guide in documentation
Comment #13
andypostWhat's left here to approve?
Comment #14
yoroy CreditAttribution: yoroy at Roy Scholten commentedAbout the ”experimental” warning. We could:
- Show a more prominent warning directly in this list
- Add a confirmation dialog when picking an experimental profile
- Have a (persistent) message inside the site after installation (+ on the status report page?)
- Use some of the sample content itself to remind people
Comment #15
lauriiiComment #16
ckrinaAbout showing a more prominent warning in the install page, here's a suggestion: maybe we could try to separate it a little bit from the other elements from the list. I'm thinking on not giving the idea that they are exactly the same. Maybe even moving the experimental one at the bottom and adding a title above it like "experimental profile" (even some toggle info text to give some more info?). Just some ideas.
Comment #17
adamjuran CreditAttribution: adamjuran at Forum One commentedI've created an HTML mockup of @tkoleary 's screen shot in #3 and attached both the HTML and a screenshot. The mockup has inline CSS which would probably go at the bottom of core/themes/seven/css/theme/install-page.css if this approach is accepted.
Comment #18
ckrinaAs @lauriii commented on #2870863: Create plan for supporting experimental installation profiles (comment #3):
It answers some @yoroy’s proposals on #15. So what I said in comment #16 doesn’t applies anymore.
As discussed in the Out of the Box meeting. I’ll give a try to @tkoleary’s comment #9 and propose something in the next days.
Comment #19
ckrinaHere are 3 similar approaches for tagging an installation profile as experimental. In all of them I moved the Experimental profile at the bottom of the list to not encourage using it as the default/first click.
A. As suggested by @tkoleary in #9, I changed the Experimental label to red color. It looks like this one is the most suitable with less visual impact.
B. Added a prominent red-warning tab to show clearly that it is experimental. It is too much for me, but I thought it might be good that other people sees it.
C. A proposal between A and B. More prominent and clear than A, but without using that alarming tone. I like this one for the "warning level", but the problem here is that it introduces a new component/element to core that I'm not sure it is going to be useful anywhere else.
Thoughts?
Comment #20
ckrinaDuring this week's UX meeting we discussed @tkoleary's design with #19 suggestions.
There was general agreement on using another color than red (to keep it only for errors), so I changed the label "experimental" to yellow used for warnings.
2. When selecting the experimental profile we could have 2 different behaviors:
A. Showing a message inside the profile's bow warning about using it.
B. Nothing happens when the profile is selected, but after pressing the "Save and continue" button a warning message would appear in a modal where we could accept/continue or cancel and going back to selection profile page.
Any other opinion/idea?
Comment #22
ckrinaComment #23
webchickI was asked by the team today if this issue is a requirement or not for getting Umami into core in a tagged release, and relayed this question onto the core committer team. Consensus from those present (@xjm, @Dries) was that something along these lines is a requirement in this case, because although the installer screen has nothing to do with the profile itself, the profile does expose a new concept of "Experimental" profiles, and so it is this initiaitve's responsibility to handle the implications of this.
The concern is that while we initially tried to handle Experimental modules with simple text cues (in module name + description + package), we found this to be ineffective, and people were rampantly installing e.g. Content Moderation despite the fact that there was no upgrade path or API backwards-compatibility. (There were warnings about this, of course, but they were clicked past.)
Installation profiles make this basic "people don't read" problem even worse, because while you can uninstall a module, you can't ever go back and reset your decision to build off a particular installation profile. And when a future version of 8.x ships and changes the data model/API/whatever, and there's no upgrade path/BC provided, this will completely hose peoples' sites. :\
So, a couple of problems we need to design for:
A: During installation time. This is the point of no return, and thus the most important place to get this right. (This issue.)
B: While they're using it after they install. Continuing to annoy them in some visual way (hook_requirements() error on admin panel, prominent CSS banner that triggers once a day, etc.) if the site is still up standing after 24 hours. (or whatever.)
It sounds like A is definitely a requirement, and B might also be, so it'd be worth putting some thinkering around that issue.
I think for this issue, the simpler the better, so if we could move adding screenshots to profiles to a separate issue, and keeping this one focused on getting the experimental warning right (or vice-versa) this would be good. We could also do more in the name + description of the profile (for example, name it "Quick demo," call it a "fully-featured test site") to help scare people away...
We have a core committer call tomorrow, and I'll try and extract any further design requirements from that, but for now, wanted to update the team on the situation so we have as much of a head start as possible.
Comment #24
Tanvish Jha CreditAttribution: Tanvish Jha at Google Code-In commentedI feel that comments #19 A and #20 2B can help out much efficiently in warning the user about the experimental installation. As far as a persistent warning is concerned, I totally agree with you.
Comment #25
kreynen CreditAttribution: kreynen at University of Colorado Boulder commentedIt would really suck to see #1356276: Allow profiles to define a base/parent profile delayed or derailed for this, but maybe there's a way that Umami could actually move sub-profile support forward. Is there a technical reason demo_umami can't be configured as subprofile of Standard or Minimal?
Looking at https://github.com/gareth-fivemile/demo_umami/blob/master/demo_umami.inf... and http://cgit.drupalcode.org/drupal/tree/core/profiles/standard/standard.i..., the only additional requirements for the Standard profile are comment and big_pipe.
Responsive_image is added by demo_umami, but additional modules being added by a subprofile is normal.
A big win of this change would be Umami in core would make it easier to test the subprofile functionality and be an example of profile inheritance in action.
Comment #26
yoroy CreditAttribution: yoroy at Roy Scholten for Dropsolid commentedLets not introduce new concepts for how this works less than 2 weeks before the deadline :)
Comment #27
yoroy CreditAttribution: yoroy at Roy Scholten for Dropsolid commentedI think the real point of no return is not on the installer but somewhere along the path of starting to modify, edit the Umami site. Not when choosing to install a test, but when you've changed so much that you become invested in what you have and want to keep it.
So, I don't agree that A (on the installer) is more important than B (while using, after install). Since we already know people don't really read, hanging this on A gives us only a single opportunity to get the point across, at a time when you can't even know what you are about to get/might lose. Instead, a (semi) continously nagging message/banner/notification in the site itself could be more effective because it would be visible more often.
Comment #28
yoroy CreditAttribution: yoroy at Roy Scholten for Dropsolid commentedHere's a first stab at listing Umami, using only text to explain what's up:
Umami (experimental)
Explore and test Drupal features in this demo food magazine site. Do not use this as a starting point for a production site.
("live" is probably better than "production" site)
Comment #29
Tanvish Jha CreditAttribution: Tanvish Jha at Google Code-In commented@yoroy as mentioned by webchick in comment #23, we also need to factor in the "people don't read" issue. How about we start the line 'Do not use this as a starting point for a production site.' from a new line and give it a yellow/red color? We can also add an exclamation at the beginning of the sentence.
Comment #30
kattekrab CreditAttribution: kattekrab as a volunteer commented"Don't use this as a starting point for a live site."
Ok.
But why?
Even people who read this are likely to ignore it if they don't understand the consequences of doing so.
But Yes! A simple text warning is definitely a good MVP start.
How about...
Although I do kinda wonder if the profile should be "Demo" not "Umami" - The Theme the profile installs is called Umami, but the functionality here is what matters, not the content, so Demo makes more sense to me. So...
- Standard
- Minimal
- Demo
This is what we have as of the simplytestme site I have up at the moment.
Comment #31
Tanvish Jha CreditAttribution: Tanvish Jha at Google Code-In commented@kattekrab Since we are trying to warn users about the installation of the demo version and we are also assuming them to "not read" anything I think we should go with Demo shouldn't we?
Comment #32
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedAccessibility review of the design proposals in #3, #19, and #20.
These replace a set of native radio buttons with a set of cards that behave like a radio button set, but don't look like radio buttons. If we're going to do this, we need to provide replacements for a all of the affordances that radio buttons provide, including accessible ones. @laurii hinted at this in #7:
For sighted keyboard users, it goes a bit further than that. It's not clear (visually) that they have radio button behaviour. Native HTML5 radio buttons have styles for selected and focused states. The difference between a filled-in circle vs empty circles is a strong affordance to say you can choose something else. I don't think the thick sidebar is as strong an indication as the native one. It's like we've provided a replacement for the selected radio button, but not for the unselected radio button, or the focus state.
Here's a GIF screen recording of the keyboard-only experience of the profile selection screen, as a reminder of the states we'd need to replace.
We haven't provided any custom styles for selected/focussed radio buttons; here we see the default styles form Chrome.
So perhaps we can have a clearer indication of selection, focus, and radio-button behaviour by having a visible radio button (native input, or fancy alternative) inside each card? Including an equivalent to the empy non-selected radio. There might be some styles in the media initiative image browser dialog we could re-use, where they indicate which images are selected?
The usual way to implement these kind of clickable tiles is to use native HTML radios (or checkboxes), make the
<input>
elements visually hidden, and move all the visible styling (selected, focused) to the<label>
elements, with selectors likeinput:focus + label
andinput[checked="true"] + label
. This approach leaves them unchanged as far as assistive tech is concerned, but for sighted keyboard-only users (without assisitive tech) we would need styles to convey the radio button behaviour, including focus.Another interesting thing about these designs is the thick left-hand bar to indicate the selected item, spans both the label AND the description. Styling this might be awkward with Drupal's default markup. Some approaches are:
:focus-within
selector is for, but we'd need a polyfill for IE11 at least.<label>
, and usearia-labelledby</code and <code>aria-describedby
to associate these correctly with the<input>
.The "experimental" badge should form part of the accessible name of the radio button (i.e. inside the
<label>
, not a sibling).Comment #33
ckrinaThank you @andrewmacpherson for the accessibility review, we might have to rethink it a bit if we finally go to that direction when we add images to the profiles.
For now, I think the MVP for this issue needs to leave out of scope the images and focus on the Warning message. And based on previous messages, I am not sure if we are now talking or not about changing the current design for this 8.5 MVP anymore.
Anyway, here is another quick design proposal with the warning message, without the images, and some suggestions mentioned like labelling it "Demo".
Comment #34
ckrinaAlso, I've just created the issue for the "problem B": #2934374: Add permanent warning message for experimental profiles to avoid its usage on production sites.
Comment #35
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedThe warning message appears dynamically after selecting an experimental radio button, yes? If so, it's a change-of-content that needs to be conveyed to screen readers. The simplest approach is to wrap the message with
<div role="alert">
or<div role="status">
. Both roles are implicitlyaria-live
regions with different assertiveness. I think we should include the profile name in the message for clarity: "Umami demo is a sample website". You never know, we may end up with several experimental profiles one day.We could use
Drupal.annouce()
to convey the new message, but that's best foraria-live
messages which aren't also visible.FWIW, I prefer the "are you sure" dialog from #20. It's a more pronounced pause for consideration, and is similar to the extra step when enabling experimental modules.
Comment #36
markconroy CreditAttribution: markconroy as a volunteer and at Annertech commentedWe chose demo_umami rather than just demo or umami or umami_demo as the profile name to allow for adding more demo profiles in the future, such as demo_sport or demo_marketing or whatever, with demo_* as the namespace.
Just thought I'd post that here for the reason we have it - hope I'm not derailing things.
Comment #37
ckrina@andrewmacpherson I agree with you with the more prominent message, I prefer the dialogue too. But I also think that maybe for the 8.5 MVP on January 15th the regular warning message could be enough.
Comment #38
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedComment #39
ckrinaOk, after yesterday's UX meeting feedback I removed the "Experimental" label because it seemed to take too much attention and instead a Warning seemed more like a Call to Action.
Also added bold font weight to Standard and Minimal profiles label, and kept regular for the demo.
Comment #40
yoroy CreditAttribution: yoroy at Roy Scholten for Dropsolid commentedIn general: The tricky thing is that we want to de-emphasize 1 item in the list. Because it's only one item that is different, it automatically becomes "special" and attracts attention because of that. Add to that the already very basic presentation of Standard and Minimal, which leaves very little room to create an even more modest presentation for Umami. Lighter colors and/or smaller text would make things inaccessible because too low contrast.
So another way then would be to enhance the presentation of the stable profiles (as @ckrina illustraties in #39 above) :
a: Labels bold + larger font size
b: Labels bold only
But maybe an even better approach would be to stop thinking about promoting/demoting certain items. What if we instead only express that one of these is *different* from the others? Not more or less important/risky/desirable but just different:
c: Draw a line to visually separate "Stable" from "Experimental" install profiles.
With this approach we don't try to give meaning (relative importance, risk, desirability) to the visual presentation of the profiles themselves. Instead we simply draw a line. What that separation means is then handled through content:
- the "Demo:" prefix in the profile label
- the profile description
- the warning message shown on selection of the experimental profile
Comment #41
xjmOne question about the mockups -- I'm assuming "suitable for advanced users" is just from copying from Minimal and we'll also review the proposed text in this issue?
Comment #42
yoroy CreditAttribution: yoroy at Roy Scholten for Dropsolid commentedyes, took a shortcut there :)
Comment #43
yoroy CreditAttribution: yoroy at Roy Scholten for Dropsolid commented@ckrina has a screenshot with actual words for Umami in #39
Comment #44
xjmAnother approach I thought of to help with the "specialness" problem is that the warning would not be displayed on page load, but we would only reveal a warning after clicking on/selecting the radio button (edit: inline in the form with JS form states, before submitting the page). That way it's not an annoying, scary, and bewildering confirm-confirm-confirm form, plus the change on the page helps draw the user's attention to what the message actually says.
Comment #45
yoroy CreditAttribution: yoroy at Roy Scholten for Dropsolid commentedAh, sorry if that was not clear, but that has always been the intended behaviour for the reasons you mention :). #39 hints at this but we didn't mention it explicitly.
Comment #46
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedQuick text review:
Nice.
I think this is too long and also repetitive combined with the above.
Could it simply be something like "Install an example website that shows off some of Drupal's capabilities" instead?
That isn't a sentence, and the double "website" is confusing.
I actually think this warning should just be removed entirely - see my comment at #2934374-26: Add permanent warning message for experimental profiles to avoid its usage on production sites for some of the specific reasons why.
Comment #47
Dries CreditAttribution: Dries commentedI like option C best.
I do have a few thoughts -- they are minor and non-blocking. Assuming Umami is stable,
Try to look at the install screen through the eyes of someone that knows little to nothing about Drupal. They'll lean towards what is selected by default (i.e. 'Standard'). The name 'Standard', the description, the layout/order of the information, and the default selection might make them believe that they should go with 'Standard'. From the description, they can't tell that this will give them an 'empty' site or that Standard is for people that know enough about Drupal already.
Comment #48
markconroy CreditAttribution: markconroy as a volunteer and at Annertech commentedI'm with @dries (for the most part) on this one. I'm not too fussed if demo_umami is at the top or the bottom (bottom might be better in case we have more demos in the future.
But I agree we need to promote this and get people to install it. The whole point of the initiative was "Drupal doesn't do much 'out of the box'" and now we have a food magazine website to show. Are we really going to say we spent too years trying to show that Drupal is pretty cool out of the box, and then do our best to ensure people don't try this as their first experience? Why build it if we are not proud of it and are afraid that people will install it?
My preference would be for the three profiles to have the same weight (bold title, standard weight description) and then the line/border dividing up between the standard/minimal and the demo(s).
Comment #49
yoroy CreditAttribution: yoroy at Roy Scholten for Dropsolid commentedAgreed. We have direction so lets proceed with a patch. Keep in mind that the bold labels arent there now so the minimum viable change is to introduce the line. Umami came in last and still has to prove itself so it gets added to the bottom of the list.
Comment #50
yoroy CreditAttribution: yoroy at Roy Scholten for Dropsolid commentedComment #51
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedRe: #47
Hmm, what if we didn't pre-select anything, so they have to make their own decision?
Comment #52
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedTagging for a11y review later. I think this will work, but I want to double check how the warning comes out for assistive tech users. Ping me when there's a patch..
Comment #53
kreynen CreditAttribution: kreynen at University of Colorado Boulder commentedWhen making these decisions, please keep in mind is that the profile selected is written to the settings.php file on install. I haven't tried this on Acquia recently, but on Pantheon this means that once a user selects the profile wiping the instance and trying to re-install by selecting a different install profile results in an error in the install.
I'm guessing that nearly all Drupal previous installs done through the UI selected Standard and never tried to change to Minimal after the doing that. With a demo install as an option, the desire to change what you selected will likely come up more often.
Comment #54
kattekrab CreditAttribution: kattekrab as a volunteer commentedSo, by making "Demo: Umami" the default install what happens when people start building a website with it?
I agree that it should be the default, but I've read (in the other threads) about the concern that people will start to build on top of it, and that somehow creates problems.
To be honest, it would be better if we resolved whatever those problems are, than frighten people into not checking out this demo.
Any anyway, In #30 I asked "Why" shouldn't I start building with Umami? Have we got a clear answer, anywhere, on that yet?
Comment #55
ckrina@kattekrab the main reason is backward compatibility. We want to showcase what's on Drupal and keep doing that for future releases :)
For example, we'll want to showcase modules related to layout building (Layouts, ...). But right now they are not stable yet so now we can't build the demo based on that. If we build the recipe detail page in a certain way (fields in the template right now) and we are limited to give backward compatibility, we'll never be able to improve this demo with the new functionalities that might make it to core in the future.
Comment #56
kreynen CreditAttribution: kreynen at University of Colorado Boulder commentedAnother issue is that future core updates to sites that used Umami as their install profile are very likely to fail or result in very inconsistent sites. It is very difficult to provide an install profile as a starting point that allows users to change the content and configuration and then be able to reliably apply updates after that. In other threads, I've been told that the Umami team's plan to address that difficulty is to simply tell users that upgrades are not supported.
To see the next Umami demo site, the users have to start over, wipe the db, update the code, re-install Drupal using Umami and re-import the updated demo content.
Comment #57
yoroy CreditAttribution: yoroy at Roy Scholten for Dropsolid commentedThat is correct.
Comment #59
kattekrab CreditAttribution: kattekrab as a volunteer commentedThank you @ckrina and @kreynen
So... could this be the start of some accurate, user centric, wording/documentation?
Umami has been designed to demonstrate the features and capabilities of the Drupal platform. Installing this demo profile, and changing the design and content will give you a chance to learn, discover and experience what's possible with Drupal. Features of this profile will change with each release in order to showcase what's new and innovative in Drupal.
To start building your own website, you should use the Standard, or Minimal profile. For more information on this, along with HowTo guides and site building recipes, see the Documentation and Tutorials section of Drupal.org.
Important Note: Do not use Umami as a foundation for your new website because you will not be able to maintain or upgrade it in future. This install profile does not have an upgrade path. If you try to upgrade a website built with this profile, it will break.
edit: changing the order of these paragraphs.
Comment #60
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedThere is no clear answer to this question yet. See my analysis in #2934374-26: Add permanent warning message for experimental profiles to avoid its usage on production sites and discussion in subsequent comments for more.
Regarding the subsequent comments here in this issue:
I don't understand this argument. The layout modules will be optional modules, even after they are stable. So the theme can't assume that everyone will have them enabled. That is not for "backwards compatibility" reasons; rather, it's simply because someone can (1) Install the demo profile, (2) Disable the layout modules via the admin UI, and (3) Expect that the site doesn't completely explode.
That is not to say the profile can't install those modules by default and that the theme can't be optimized to work with them; it certainly can. And it certainly doesn't have to maintain backwards compatibility for existing sites (in terms of making everything look exactly the same as it did before). But it should work and look somewhat reasonable/acceptable for sites that don't use the default configuration, regardless of whether the site got that way because someone was playing around with the demo and changing configuration, or because they installed the site on an older version and then updated. The considerations should be exactly the same.
I don't understand this argument either. In what way would an update "fail"? The profile is mostly configuration, so an update shouldn't have any effect by default. If the profile wanted to offer some way for an existing site to get the new configuration, it would clearly be opt-in (think
drush features-revert
in Drupal 7), so it wouldn't break anyone's site unless they deliberately accepted the changes.And if there is no mechanism to do that, that's fine also. There is no harm in an older site being inconsistent with a newer one.
Comment #61
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedThis issue also now seems to have a lot of overlap with #2938185: When installing Umami, only show warning if 'Demo Umami' radio button is selected (and ensure that it is obvious that warning message only applies to the Umami profile).... I guess the question to answer here is whether it makes sense to have warnings on (experimental) install profiles as a general feature of the installer screen. I don't think there have been good reasons given for that, but there could be reasons for an extra "informational-style" message instead (as discussed in that issue).
Regarding the text in #59 I think that (with some edits) this could maybe be useful for the profile's Help pages (hook_help() implementation)? I'm actually not sure if a profile can have help pages, though? If it can, it could also be a good page for the current message in the toolbar to link to, since the current one doesn't link to a sensible place currently (see #2938189: [META] Finalise the wording of the messages in installer, toolbar and on the status report page).
Comment #62
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer and at Annertech commentedI'm a bit confused at how many related issues have sprung up. I think we should concentrate on this one rather that evolving the umami-specific workaround.
Anyhow, over at #2938185-5: When installing Umami, only show warning if 'Demo Umami' radio button is selected (and ensure that it is obvious that warning message only applies to the Umami profile) there was a proof-of-concept patch, and I gave it a look for accessibility. I expect the design here will evolve further, but so this is just an interim impression of how we convey the warning message to assistive tech.
Rest of comment is a mostly re-post from the other issue....
Accessibility review. (specifically, about patch #5 from #2938185-5: When installing Umami, only show warning if 'Demo Umami' radio button is selected (and ensure that it is obvious that warning message only applies to the Umami profile))...
1. Remove the
role="contentinfo"
andaria-label="Warning message"
form the amber warning box. This role is intended for regions which contain information about the page as a whole. It's not appropriate for this warning message which applies to a particular selection among the radio buttons. (It's not the correct role for the existing messages in the help region either, there's an issue about that already.)2. The warning message isn't conveyed to assistive technology. On page load, the warning message has CSS
display:none
from the States API:visible
. So the information isn't conveyed to assistive tech. The warning needs to be conveyed to AT users when the Umami radio is selected.Possible approaches:
aria-describedby
to programatically associate the Umami radio button with the warning message. This means the umami radio button will be described by TWO elements (the warning first, then the form #description) while the Standard and Minimal will be described by one element (the form #description).role="alert"
oraria-live="assertive"
on the warning message (it must be on same element which hasdisplay:none
toggled. This might not be a robust solution! In theory this should cause the message to be announced immediately when it becomes visible, but in practice some screen readers don't give priority to assertive ARIA live regions yet. The message may not be announced. Needs testing.Drupal.announce()
to convey the message when it appears. This also needs testing, there's no guarantee it will be spoken. I expect some screen readers will treat the radio button's<label>
andaria-describedby
as higher priority, and omit to announce the warning.My hunch is the first one will be the most reliable, but we'll see. I'd like to play around with these approaches with some screen readers. I can adapt some code from the patch at #2938185-5: When installing Umami, only show warning if 'Demo Umami' radio button is selected (and ensure that it is obvious that warning message only applies to the Umami profile) to do that, and report back.
Comment #73
mgiffordTagging for https://www.w3.org/WAI/WCAG21/Understanding/name-role-value
Comment #74
xjmFixing attribution.