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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

larowlan created an issue. See original summary.

tkoleary’s picture

Assigned: Unassigned » tkoleary
tkoleary’s picture

Here's my first pass. Added some copy too.

larowlan’s picture

<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?

tkoleary’s picture

@larowlan

I'd keep it simple for now.

tkoleary’s picture

Status: Active » Needs review
lauriii’s picture

I 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!

ckrina’s picture

Great 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.

tkoleary’s picture

@ckrina

maybe it makes it difficult for the user to realize about it.

That's a really good point. What if we made it red?

tkoleary’s picture

Issue summary: View changes
FileSize
115.73 KB

@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.

tkoleary’s picture

@laurii

Added to seven guide in documentation

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

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.

andypost’s picture

What's left here to approve?

yoroy’s picture

About 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

lauriii’s picture

ckrina’s picture

About 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.

adamjuran’s picture

I'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.

ckrina’s picture

Assigned: tkoleary » ckrina

As @lauriii commented on #2870863: Create plan for supporting experimental installation profiles (comment #3):

It is important that users understand the implications of installing an unstable installation profile. However, because this is a demo, we don’t want to pollute the installer with too many warnings (like module installer).

On the installation page, only a small warning text will be shown.

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.

ckrina’s picture

Here 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?

ckrina’s picture

FileSize
270.94 KB
242.67 KB
131.87 KB

During 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?

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

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.

ckrina’s picture

Assigned: ckrina » Unassigned
webchick’s picture

I 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.

Tanvish Jha’s picture

I 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.

kreynen’s picture

It 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.

yoroy’s picture

Lets not introduce new concepts for how this works less than 2 weeks before the deadline :)

yoroy’s picture

I 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.

yoroy’s picture

FileSize
307.71 KB

Here's a first stab at listing Umami, using only text to explain what's up:

screenshot of choose profile step in the installer with Umami as a third option at the bottom of the list

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)

Tanvish Jha’s picture

@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.

kattekrab’s picture

"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...

Umami (experimental)
Explore this demo to see what Drupal can do. Warning: Don't use this to start building your real site, as [bla bla bla] for more info see [link to Umami docs].

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.

Tanvish Jha’s picture

@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?

andrewmacpherson’s picture

Accessibility 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:

I'm also slightly concerned if it's obvious for users what is the clickable area.

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.

Screen recording, shows visual styles for selected and focused states of native HTML radio buttons.

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 like input:focus + label and input[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:

  • This is a good example of what the new :focus-within selector is for, but we'd need a polyfill for IE11 at least.
  • Or, we could move the description and image inside <label>, and use aria-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).

ckrina’s picture

Thank 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".

Installation profile

Installation profile Demo selected

ckrina’s picture

andrewmacpherson’s picture

The 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 implicitly aria-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 for aria-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.

markconroy’s picture

We 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.

ckrina’s picture

@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.

andrewmacpherson’s picture

ckrina’s picture

Ok, 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.
installation profile

installation profile

yoroy’s picture

In 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) :

3 combined screengrabs illustrating 3 different options to discern stable from experimental install profiles on the profile selection screen of the Drupal installer

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

xjm’s picture

One 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?

yoroy’s picture

yes, took a shortcut there :)

yoroy’s picture

@ckrina has a screenshot with actual words for Umami in #39

xjm’s picture

Another 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.

yoroy’s picture

Ah, 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.

David_Rothstein’s picture

Quick text review:

Demo: Umami Food Magazine

Nice.

Install with the Umami food magazine demonstration website, a sample Drupal website that shows off some of the features of what is possible with Drupal "Out of the Box".

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?

This is a sample website, you should not use it as the basis for your website.

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.

Dries’s picture

I like option C best.

I do have a few thoughts -- they are minor and non-blocking. Assuming Umami is stable,

  1. I'd consider putting Umami above Standard and Minimal. Rank them from novice to advanced.
  2. I'd consider making Umami the default instead of Standard.
  3. I'd consider being more explicit who each profile is for.

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.

markconroy’s picture

I'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).

yoroy’s picture

Agreed. 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.

yoroy’s picture

Status: Needs review » Needs work
andrewmacpherson’s picture

Re: #47

they'll lean towards what is selected by default

Hmm, what if we didn't pre-select anything, so they have to make their own decision?

andrewmacpherson’s picture

Tagging 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..

kreynen’s picture

When 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.

diff of settings.php changes

install error after wiping db

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.

kattekrab’s picture

So, 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?

ckrina’s picture

Why shouldn't I start building with Umami?

@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.

kreynen’s picture

Another 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.

yoroy’s picture

That is correct.

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

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.

kattekrab’s picture

Thank 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.

David_Rothstein’s picture

Any anyway, In #30 I asked "Why" shouldn't I start building with Umami? Have we got a clear answer, anywhere, on that yet?

There 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:

  1. @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.

    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.

  2. Another 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.

    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.

David_Rothstein’s picture

This 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).

andrewmacpherson’s picture

I'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" and aria-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:

  • Use an 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).
  • Use role="alert" or aria-live="assertive" on the warning message (it must be on same element which has display: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.
  • Use 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> and aria-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.

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

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.

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

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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.

mgifford’s picture

xjm’s picture

Fixing attribution.