Accessibility Plan for Layout Builder

Thanks for starting this @tedbow

We need an a11y meta plan, but it has to include more than just input methods. So I'd like to broaden the title scope, and make input methods a sub-heading here.

Some other aspects we'll need to address include:

• The way we describe the UI to assistive tech. It has to be percievable and understandable, so a user can make sense of it, before they even begin to syart moving blocks.
• Documentation. I have a feeling this will need a manual. The experimental Help Topics module will help, but we may have to wait on it a while. Tour module is also something to cobsider, though that has numerous accessibility problems of it's own.

What inputs methods should we support?

All of them! Well, at least as many as we can think of. Plus all of the ones that don't exist yet.

That isn't whimsy - it's from the normative parts of WCAG. "Principle 4: Robust is about ensuring compatibility with as many technologies as possible: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

WCAG Guideline 4.1 Compatible goes on to Maximize compatibility with current and future user agents, including assistive technologies.

The point being, we'll never know what input method someone wants to use, in the same way that we'll never know what disabilities a user has, or what situation they are in.

Also, Drupal's values say we build software that everyone can use.

The range of tech I'm currently thinking of as a good basis is:

• Mouse, and similar "single" pointers (we must NOT assume multi-touch can be used)
• Touchscreen (which has a some important differences from a mouse, notably the lack of hover capability).
• Keyboard (and by extension technologies which emulate a keyboard, though we'll never know they're being used)
• Screen readers (whether speech synthesis or braille output is used)
• Screen magnifiers (which are highly varied)
• Switch access scanning (macOS, iOS and Android have built-in systems)
• Speech control
• User stylesheets (it's impossible to know how these might be used, but it's a good idea to minimise inline styles and refrain from the !important keyword) Updated (13th Nov 2018): let's not worry about this. User stylesheets are more of a last-resort work-around for some users, not something we can practically address here.

What does rest core support?

It's a moot question, because if something else in core doesn't work well with any input methods, then that would be a bug as far as WCAG's Robust principle is concerned, and we should improve it. So this isn't a good starting point to base our intentions on.

However, we can turn this the other way around, to say that it isn't layout builder's responsibility to fix deficiencies in other parts of core.

For example, we need to improve Drupal core's robustness for Windows' high-contrast mode, but that should mostly be addressed in Bartik, Seven, and Classy. Yet the layout builder is intended to work with the website's default theme, including custom ones presumably. So there may turn out to be some things we can do with any CSS provided by the layout builder module to help it work with Windows high contrast mode.

Brain dump about addressing speech control....

To facillitate moving blocks with speech control, I think we'll need, at minimum...

EITHER: At least one always-visible control per block

Approach 1: Each block has an associated button which reveals a menu of operations which can be carried out on that block. Among these are commands to:

• Move the block up/down in this region
• Move the block to a different region in the same section (using directions, or maybe names of regions)
• Move the block to a different section
• Remove the block from the layout
• Other operations and/or block settings.

OR: a single control which serves as the first step in a process, where a subsequent step allows specifying which block to operate on.

Approach 2: A button called "move block". Pressing it activates a dialog. Inside there is a select input, where a user can indicate which nlock they want to move. A second select input has a list of destinations it can be moved to.

Approach 3: A "show all block controls" switch lets the user change how block controls are shown across the entire layout builder UI. One option makes the controls visible for all blocks at once, the other makes them visually hidden unless hover/focus is within a particular block's controls. Speech control users will benefit from showing the controls for all blocks at once. This approach might be used in conjunction with approach 1.

Approach 1 will be great for speech control users and may also benefit switch-access users, but it adds visual clutter, which will get in the way of users who want a realistic preview.

Approach 2 isn't very elegant at all. I include it as a contrived example of of what we might end up with if we treat speech control as something to be fixed as an afterthought.

I think approach 3 could be quite elegant in practice. It gives the user choices to support their chosen input method(s), and still supports the use-case of a realistic preview. It could also work well in combination with some other toggles, such as show/hide block content, and show/hide region labels.

Another brain-dump, this time about how we describle layout builder to screen readers.

I waa thinking out loud in the #layouts Slack channel earlier today.

andrewmacpherson [10:31 PM]
Is there a schema for `*.layouts.yml`? I'm trying to understand
whether keys there are mandatory or optional.

and also what human-readable strings layout plugins have.
I found the Annotation class

samuel.mortenson [10:34 PM]
Ah - that's what I was going to suggest :slightly_smiling_face:
The schema is....lacking. Unless I'm missing something. See
`core.data_types.schema.yml`

andrewmacpherson [10:34 PM]
Layouts (i.e. sections) and Regions both have human-readable labels.
That's a good start. (edited)

timplunkett (he/him) [10:34 PM]
plugin definitions don't have schemas
that's for config (plugin or otherwise)

andrewmacpherson [10:35 PM]
Is icon map mandatory?
.cos it looks very usefull and not just for icons....

timplunkett (he/him) [10:35 PM]
it says optional
all of the optional keys say so in their `@var`
see also https://www.drupal.org/docs/8/api/layout-api/how-to-register-layouts
Drupal.org
How to register layouts
The Layout API is also included experimentally since Drupal 8.3.x core
and most documentation to be found is based on changes introduced
since Drupal 8.5.x. There are several ways to provide a layout. We'll
discuss each in the sections below, starting with the simplest, most
common case and building up to some of the more advanced techniques!
Mar 29th, 2017

samuel.mortenson [10:36 PM]
icon map is pretty cool, unbiased opinion here

timplunkett (he/him) [10:36 PM]
see also \Drupal\Core\Layout\Icon\SvgIconBuilder

andrewmacpherson [10:37 PM]
optional, found it

timplunkett (he/him) [10:38 PM]
oops, description is missing that in its `@var`
:slightly_smiling_face: but mentions the optionalness in the docblock
core/modules/layout_discovery/layout_discovery.layouts.yml is a good example

andrewmacpherson [10:38 PM]
I'm thinking about how to describe a layout, empty or populated, to a
screen reader user.
"optionalness". love that.
optionality?

andrewmacpherson [10:47 PM]
I'm thinking of some of the ways that caption-and-summary can help a
user understand a table, _before_ they start exploring it by row and
column. https://www.w3.org/WAI/tutorials/tables/caption-summary/
(edited)
Lsyouts ain't tables of course, but a similar approach may be useful.
So I'm thinking about whether we can programatically derive useful
summaries based on the `*.layouts.yml`
Layouts and regions have labels which is cool.
But sections don't have names. Might have to number those.
aria-label="Section 2, Left region"
preferably aria-labelledby, but that's the idea.

samuel.mortenson [10:59 PM]
Section labels could be the layout label and a index, but that might
be awkward too. Just numbering theme seems more accurate
Section 1, One Column, Left region
One Column 1, Left region seems awkward, for instance

andrewmacpherson [11:02 PM]
I keep thinking `*.layouts.yml` is config and have remind myself
they're not config despite being yaml
Are region and layout labels translatable? I expect so.

samuel.mortenson [11:16 PM]
That is a good question...the answer is yes, but I'm wondering if user
interfaces presenting them have to explicitly wrap them in `$this-t()`
if they've been defined in YAML. If they're defined in an annotated
class that class chooses if they're translatable or not
:mindblown:

Yes, that's pretty much what I was thinking of for the screen reader Section summaries (akin to table summaries). These would be conveyed as the Accessible description for the section (via aria-describedby).

If we have to compute this summary that's OK, I think. The layout description key could be employed, but the annotation class says it's optional. Maybe we compute the summary if the layout doesn't have a description?

The sections and regions would also need Accessible Names (via aria-labeledby). These would be shorter, like "Section 2" and "Left region, section 2".

Of course we would want to put a caveat that these regions might all just be displayed in a single column at narrower widths.

We could just list them, in the array order from the regions key, and dodge that issue

Hmm, the layouts in layout_discovery.layouts.yml don't have the description key.

We could use these descriptions when the "Choose layout" dialog is open and a particular layout is tabbed to.

Yes, they'd be serving as a text alternative to the icon, which conveys useful information. Would a screen user be at a disadvantage compared to someone who could see the label and icon, vs the label only? Probably. Especially for a more complex layout.

But for simple layouts it would be overkill. "One column - a one column layout."

If the icon_map and description keys are optional, we may have to treat it the same as a FAPI description - a recommend that developers provide one, but omit the description if they don't.

Was reading Approach 2 in comment #7 and had an idea which builds on that.

Instead of showing a dialogue when you select "Move block", "Move block" could reveal boxes in each region of each section. These boxes are displayed between each block (or just one for an empty region), they would be as wide as the blocks are and have a noticeable height (possibly with a grey dotted border and grey text). Clicking on one of these boxes moves the selected block to that position.

As far as I can see this approach meets a number of requirements:

• It could be quicker than movement arrows and even easier or quicker than dragging a block.
• It would work for mouse, touch, keyboard, heck it could even work for voice activated input ("move block z between block x and y", if we ever support that).
• As someone who is visually impaired and has experience of using screen magnification and screen readers it would work very well: since with a magnifier the user can freely navigate around until they find the location where the block should be placed without having to drag a block around with them potentially obscuring their view, and for screen readers it would be easy to describe each possible placement when the screen reader moves over that area e.g. "between block x and y".
• This approach seems even better for those who have no usible vision using screen readers since they don't need to worry about visiually contextual information to move a block to a specific position (such as trying to figure out what "left", "right", "above" and "below" actually looks like, with simple movement controls this would be a concern), but instead if they know they want block z to be between block x and y they can just move around the layouts until they find that position.
• This approach is also viewport independent and would work effectively regardless of the styling and current contextual positioning of rows/columns meaning there is no need for any complex JS based guess work to identify what effect any movement controls would have in the current context. It would also be much more reliable than any kind of movement controls since it makes no assumptions about the structure and theming, nor does it need to be aware of the current layout of regions at any given moment (which can change depending on the size of the viewport, e.g. 2 column turning into one column).

I'm sure there are probably other advantages but those are the ones I could think of. If I get a chance I might try and mock up an image to better show what this might look like in reality.

Thanks
-Aaron

Update: added another advantage about being viewport and context independent.

Thanks @AaronMcHale, that's the kind of idea iteration we'll need. I think I disagree with the relative merits of the points you make, and who benefits most from each. But I'm still digesting it. I'll provide a fuller response soon.

Meanwhile, I see @tedbow made a demo, and I left some comments at #2995689-28: Allow reordering blocks without a pointer device. Those aren't exhaustive though.

I'm forming more ideas about some ways the UI could work for a wide range of interaction methods. I'm picturing ~3-4 controls whose display can be toggled (off/some/all). They could live in a toolbar next to the save and revert buttons.

The idea is that the UI could be adjusted in ways that would be of benefit for users in multiple circumstances, with various disabilities and/or interaction methods.

AND those UI adjustments would have clear benefits to users who do not have any disabilities or assistive tech.

Example 1: To help users with screen readers to understand the layout, we'll need to provide text labels for the various sections and regions. Presumably this will involve invisible text.

But wouldn't other (sighted) users benefit from these text labels too? A "show region labels" toggle switch could help in various situations...

• Maggie uses a screen magnifier, and she can't view the entire layout at once. Making the region labels visible helps her because they act as in-situ signposts, so it's easier to understand which area she's looking at as the viewport scrolls.
• Bob is blind and does all his work with a screen reader. He has to demonstrate a landing page to his sighted colleagues in the marketing department. He hides the region labels, so they can see a more realistic page preview. After the demo, the team discuss moving some blocks to different regions. Bob makes the region labels visible so they can be clear about which regions they mean, for his follow-up notes.
• Adam is a marketer who wants to review how the layouts work in responsive design on different devices. Turning on visible labels helps him understand how the regions change position, including some regions which are currently empty.

I'm forming a few more personas and scenarios for toggling block content previews, block controls, and block admin labels. They can all help with accessiblility AND provide general utility too.

I also have a few child issues to spin. out, for things we'll have to address whatever we end up with here. Bear with me, I have a lot to brain-dump.

I think we'll ultimately need to provide multiple ways for users to achieve their tasks (e.g. re-order blocks). I don't mean that in the sense of one way for mouse users, and one way for keyboard users. Rather, I mean that there will be multiple ways to achieve it with mouse, and multiple ways with a keyboard, and so on. Some of these will hopefully overlap between different input devices.

I say this, because we're beyond standard form-based UI in Layout Builder. Here we're building more application-like UI, so we'll need more UI flexibility, like applications. Layout Builder is also the first of the authoring tools initiatives which is about providing a brand new UI, instead of improving an existing one. Compare this with the Media Library module, which introduced a nicer alternative to the existing listing, but we retained the previous listing for flexibility. With layout Builder, there is no previous UI to fall back on. Other authoring tools initiatives are still mostly form- and table-based, so far.

A minimum viable product for Layout Builder accessibility would be at least one method which works, for each user task, for each input/output method listed in #4.

But to achieve an elegant, inclusive design which works well for everyone, it will help to offer choices. This means several methods to achieve each task, which can each be operated with several different input devices. Plus ways to tailor the UI to help in different situations. Instead of putting users into silos according to their disabilities and/or technology choices, inclusive design aims to provide tools which are useful to everyone, and looks for ways to provide comparable experiences and benefits.

When it comes to the code freeze for the next minor release of Drupal core, if we're hoping to advance layout builder out of experimental, we must have the accessibility MVP. But ideally we should also have a pretty clear idea of what the "elegant, flexible, adaptive" inclusive design end-goal will look like, and have a feasible roadmap to achieve it.

(Updated) Moreover, I think we should refrain from rushing towards writing code for an MVP until we have fleshed out a bigger plan. By "at least one method per input device" I don't mean write them separately without regard for the others, or even the first idea that comes to mind. Unless we're prepared to ditch it later.

Precedent:
Desktop UIs often provide 3-5 methods to do the same operation. For instance, file managers provide ways to get info about a selected file:

• Users can summon a window with detailed file metadata...
  • Via the main application menu, e.g. under View > Get info. (This is the most reliable method for accessibility. The other methods provide convenience for many users.)
  • Via a context menu.
  • Via an optional toolbar button.
  • Via a keyboard shortcut (discoverable in the main application menu).
• Additionally some file managers make a limited subset of file info available in a special pane in the application window.
  • A side pane in KDE Dolphin shows some file info, toggled via the main menu, a keyboard shortcut, or an optional toolbar button.
  • MacOS Finder, when using the Miller-columns view, shows file info in the final column.

Once again, thanks @andrewmacpherson for all the input, lots to digest here.

As I was reading your thoughts something occurred to me, my idea in #14 could probably also benefit the drag and drop Field UI and possibly other UIs that use drag and drop (such as Block UI and other orderable Entity Lists). Then that got me thinking, if my idea could benefit other parts of Drupal, what other ideas have been mentioned and/or tried for Layout Builder that could also benefit other parts of Drupal.

Definitely Something to think about.

Marking this as a blocker, for the accessibility gate.

Dries' blog post about layout builder yesterday says we're on track to mark this as stable for D8.7.0. I'm not at all optimistic about that, because as yet there is no feasible plan for how it can be made accessible.

In #17 I said:

A minimum viable product for Layout Builder accessibility would be at least one method which works, for each user task, for each input/output method listed in #4

We don't have that yet. There are some interesting ideas in this issue, and also in #2995689: Allow reordering blocks without a pointer device. So far though, I don't think we can say we have found a feasible approach. We're in deeply experimental territory here - there isn't a well-established, reliable pattern we can just copy to make the current layout builder accessible. Essentially, we're making stuff up in a hurry, for a novel UI, with limited opportunity for design validation. There's no guarantee that users are going to understand it, or find it easy to use. That's why I'm not optimistic about it getting past the accessibility gate in time for D8.7.0.

So I want to propose an alternative MVP for accessibility - a more cautious and reliable approach, I hope. While there's no well-established pattern that can make the current layout builder accessible in a hurry, as Yoda would say, there is another...

Provide a second UI for layout builder, which users can elect to use instead of the (currently pointer-driven) visual-preview layout UI.

• It would be form-based, broadly similar to the block admin UI for theme regions.The tabledrag and region selects would provide the tools to arrange blocks.
• Both layout builder UIs would be available, so that any user can choose which one they prefer to use. There's already a precedent for this, in the way that when enabling the Media Library module, the new grid view doesn't replace the table view from Media module, but keeps it around as alternative which can be useful for anyone.
• By following an existing pattern in Drupal core, we'd be providing an admin page that many users will already find familiar. It may not be as exciting and ambitious as the visual-preview drag-and-drop UI, but there is value in providing something familiar. I suspect this may hold particularly true from a neurodiversity perspective; it's a genuinely different choice. (Caveat: I'm not particularly an expert on accessibility in the area of cognitive impairments.)
• It would be made up of elements which already provide a reasonable level of accessibility, which are already used throughout Drupal core: buttons, selects, focus styles, visible text labels for regions and blocks, headings, and tabledrag (including the show row weights option). Many of these are just plain old HTML form elements.
• The principle difference from the block admin for theme regions, is that the regions would be arbitrary. We need to provide the "Add section" functionality. My hope is that this could re-use the off-canvas dialog already used by the drag-and-drop layout builder - is this feasible?
• Another difference from the block admin for theme regions, is the larger choice of blocks, i.e. content entity fields and the new inline blocks.
• Note that tabledrag is currently broken in D8 for keyboard users, but we have a fix already close to finish, in #2725259: [regression] Table Drag handles no longer respond to up/down arrow keys.
• Aside from providing an alternative for the purpose of accessibility, I believe a layout builder based on tabledrag would provide a meaningful alternative, which will suit some tasks better than the visual-preview layout builder. For example, the current block admin for theme regions tells us which module/category provides a block. Similarly a tabledrag-based Layout Builder could provide a useful technical overview of what blocks the page has been built from. In particular, it could allow someone to see at a glance where the new custom inline blocks were being used, which isn't immediately evident in the current visual-preview layout builder. Developers, IT support staff, and content inventory reviewers are an audience who might find this useful. It also presents some different extension points to the visual-preview layout builder (like the dropbutton operations which block admin has currrently).
• The missing piece would be the visual preview, of course. However, if a user needs (or chooses) to use the tabledrag UI to build an unpublished page or draft, they can still look at the node view tab or the visual-preview layout builder tab.

How do WCAG and ATAG fit into this proposal?

• WCAG provides for "conforming alternate versions", which can be used whenever the main version can't be made accessible. Now, WCAG strongly advises against using this approach, unless no way can be found to make the main version accessible. I think we are in effectively in this situation now, although we are still exploring ideas.
• ATAG makes no specific mention of conforming alternate versions, for part A (make the authoring tools UI accessible). However in many respects, ATAG serves as an extension to WCAG. Many sections of ATAG essentially talk about how to apply WCAG to authoring tools. So I'd like to think that a conforming alternative UI may be a valid approach to ATAG. (I could be on flimsy ground with this argument, but we're already in a very experimental area, so humour me.)
• However various emerging principles of Inclusive Design DO address the idea of offering UI choices to users. In particular, see "Offer choice":
  

  Consider providing different ways for people to complete tasks, especially those that are complex or non standard.

Does this mean we're giving up on making the drag-and-drop, visual-preview layout builder UI accessible?
No! We should strive to find ways of making that usable and understandable for as many users as possible, with as many different technology choices as possible. The Inclusive Design principles also emphasize "providing comparable experience", "giving control", and "adding value" in application design. It's my hope that the ideas being explored in this issue (and the related ones) will bear fruit.

However we also need to be realistic about what we can achieve in the immediate future, and how we can bring the layout builder module to stability without leaving disabled users stranded, or forcing an untested UI on them. To be clear, the tabledrag-based layout builder UI I'm proposing here does segregate some users into the alternative UI the short term, which far from an ideal inclusive design. (It's similar to expecting wheelchairs users to use an alternative entrance at the rear of a building.) Yet, in my view, it's currently the only feasible route to provide an accessible layout builder.

Eventually, I'd like to see BOTH layout builder UIs being accessible, and offer genuinely useful choices for everyone. But let's take the time to do it well, instead of hastily bolting on fixes for one type of interaction method at a time, in a rush to ship a single layout builder UI. Let's aim to provide a more flexible and integrated set of controls, which will suit many users and tasks, in different combinations. As we build more powerful application-like features in various authoring tools initiatives, I expect we'll find other places to offer users a choice of methods to complete tasks or review information.

As a target for D8.7.0, I'd like to see us:

1. Implement an accessible alternative UI for layout builder, using familiar elements where we are are reasonably confident about the accessibility, such as the tabledrag UI I'm proposing here, AND
2. Flesh out a coherent road map for making the drag-and-drop/visual-preview layout builder awesomely accessible, flexible, and inclusive - to be implemented over the course of one or two more minor releases, in time for the D9.0.0 release.

If we can achieve those two things, I think that will have the best chance of getting layout builder through the accessibility gate.

Will backwards compatibility be an issue here? After we mark the layout builder as stable, I don't know whether that means we'll be able to make further UI changes if necessary. In any case, we also have the Drupal 9 release in our sights now, which provides another opportunity for a backwards compatibility break.

Thoughts?

This does sound like a pragmatic approach. I do think that this new concept is slightly less daunting than what had been initially considered. Thanks for laying out this plan. I'm keen on seeing what we can do to push it forward!

Who can we get to help build it?

Clarifying the title, the plan is not incoherent :)

I have been experimenting with using layout definitions with theme components. A classic example would be a card component. I have used Display Suite to provide the (tabledrag based) UI for mapping fields to layout regions, and this approach has so far worked very well. One common use case is to map a Paragraphs type display to a component template.

It would be really great to have a UI for this in core. However, the visual UI of Layout Builder is not always ideal for smaller components that might have overlapping regions for example. Also, some regions might not be visually represented at all, with fields placed in them affecting (the appearance of) the component in some other way.

So maybe this could be an additional use case for an alternative tabledrag based UI for Layout Builder? Unless there are good reasons why layout definitions should not be used in this way, of course.

#24:

smaller components that might have overlapping regions

Can you elaborate on what you mean by overlapping regions?

Can you elaborate on what you mean by overlapping regions?

A card component could have a region for an image and a region for the card type (e.g. 'Blog post'). The UI would be used to place an image field and a taxonomy term field into these regions. The card component could display the type on top of the image, say in the top left corner of the image. I'm not sure if the visual UI is ideal for these types of layouts.

I see the visual UI being useful (even for content editors) for creating full page layouts, and the tabledrag UI would be useful (mainly for site builders) for mapping entity displays to component templates.

Re #26 - I think I'm getting the picture. It seems that if layout_builder and field layout modules are both enabled, then layout builder is the only option on manage-display, for all content entity types. You can't use visual-preview (layout_builder) for node bundles, whilst using a logical-table (field_layout) for block and paragraph bundles, say?

Thanks! I'm looking for use-cases that would justify having a offering a choice of visual vs. logical UIs for layout builder, apart from accessibility alone. Now we have two.

I'm starting an issue summary cleanup, and spinning out various child issues for discussion and implementation.

There was some confusion about the way I used the phrase "coherent plan", so ditching that word.

Added #3019487: [plan] Describe layout builder UI to assistive technology

Moved the alternative UI proposal (table/form based UI) from comment #21 to an issue of it's own for discussion and/or implementation.

See #3019490: Provide a Layout Overview dialog that allows performing all actions in a text/form based method

I'm starting a must/should/nice triage, with a view to sign-off for the accessibility gate.

I think it's worth giving an explanation of how I intend to assess Layout Builder for the accessibility gate.

Firstly, further to #21, where I stated the accessibilty target I'd like to see for Layout Builder:

1. Implement an accessible alternative UI for layout builder, using familiar elements where we are are reasonably confident about the accessibility, such as the tabledrag UI I'm proposing here

   Work has started on this at #3019490: Provide a Layout Overview dialog that allows performing all actions in a text/form based method. It's a little bit different to my proposal in #21, mainly because it takes place in a dialog. However it's a creative solution which I believe can satisfy the twin goals of:

   • Serving as an accessible "conforming alternate version" per WCAG, and
   • Serving as a useful informative tool in it's own right, which anyone might use in preference to the visual layout builder for some tasks. It can likely serve as a replacement for many aspects of the Field Layout module which we intend to deprecate and remove. (Apparently Field Layout has a posse! We've heard some useful comments from people who don't want to see that experimental module go.)

   That said, there are still many gaps to addressed before #3019490: Provide a Layout Overview dialog that allows performing all actions in a text/form based method can be deemed good enough for either of these, in my view. I will add necessary extra steps there. Many improvements can be spun out as should-haves, which aren't blockers to a stable layout builder.

   Because of the, um, groundbreaking ambition of Layout Builder, and the fact that no-one else has built an accessible UI quite like it, and the overall state of the accessibility issues currently in progress, I remain of the view that #3019490: Provide a Layout Overview dialog that allows performing all actions in a text/form based method is the most reliable route to WCAG conformance.

2. Flesh out a coherent road map for making the drag-and-drop/visual-preview layout builder awesomely accessible, flexible, and inclusive - to be implemented over the course of one or two more minor releases, in time for the D9.0.0 release.

   I'm very optimistic about this part. We have a sufficient number of proposed UI improvements, and known bugs, that we can say such a roadmap exists now. Or at least it will, once I have completed triage here, filed a few more issues, and clarified the plan for some existing work-in-progress. Many important parts of the big-picture plan are progressing well.

   Many of the proposed ideas have been discussed with the Web Access team at U.C. Berkeley, so the direction has at least had some level of design validation from independent accessibility specialists (and isn't just my say-so). Aside: The Berkeley team have their own considered interest in D8 layouts; I understand the university already makes widespread use of the D7 Panelizer/Panopoly approach, which they eventually need to upgrade from.

Next: assessing Layout Builder for WCAG 2.0 conformance. This is proving rather difficult, for reasons I will outline. A large part of the difficulty is there isn't an established (accessible) pattern to compare it against.

A document that's been helpful is Glenda Sims' A11y Wars: The Accessibility Interpretation Problem. WCAG has an interpretation problem. Rather, accessibility specialists have an interpretation problem. Because the normative "letter of the law" parts of WCAG are so terse, and the informative material so extensive, it's common to find specialists whose opinions differ on whether a UI conforms to WCAG or not (and I'm just one of them). The article outlines 3 approaches to interpret WCAG.

• It's tempting to use the "minimal" interpretation; non-conformance should be proven using only the normative bits. That would make sense if we see the accessibility maintainer's role as akin to "compliance officer", but that means ignoring the "accessibility evangelist" dimension of the role. Nope.
• The "optimized" interpretation is the "spirit of the law", based on all the informative material, and consensus best practice. This is the way we would usually work as a product team. It falls down in the case of the Layout Builder, where there is no established best practice for a complex UI like this. At best, we can look at parts of it in isolation, and evaluate individual tasks; but this says nothing of whether users will be able to understand or utilize the UI as a whole. It's very different from assessing the "here is a form" admin UI which we've been building for years now, and have brought to a decent level of accessibility.
• The "idealized" interpretation at first reading resonates with what we're doing: "Even when there is no readily available solution or implementation is very expensive, the idealist meets the challenge head-on, refusing to be satisfied with mediocrity.". Thrilling stuff for sure. On the one hand, Layout Builder is indeed pushing into experimental territory. The various proposals we have on the road map amount to an ambitious and innovative attempt at creating an accessible layout builder. Where this falls down is that the approach stresses user testing with people with disabilities, and we haven't done that. Without it, assuming we are operating on this level amounts to hubris.

Another document that has helped, is the original discussion around how to define Drupal's accessibility gate. Rather than follow the letter or spirit of WCAG, it's been useful to look to the spirit and intent of our accessiblility gate. I'm still mulling this over.

One very useful policy, which @webchick points out over at #3019487-12: [plan] Describe layout builder UI to assistive technology is that major a11y bugs still qualify for going into core right up to the release candidate:

any accessibility issues that we don't have actionable solutions for yet, or other bugs that we find, are still at least "major" bugs that in most cases we'll commit and backport up until the release candidate,

That was already my understanding. It's also my understanding that major accessibility bugs can often qualify to be cherry-picked into any patch release too (I need to check the standing rules on that). These policies are very useful, in the sense that it gives me confidence that some issues can be classed as should-have major bugs, and be able go in as soon as they are ready. On that basis, I'm not averse to some creative triage of must-have vs. should-have.

I've noticed a lot of low-hanging quick-wins relating to various parts of layout builder. I'll try to spin those out as narrow-scope follow up bugs, which don't have to be considered stable blockers.

Completed must/should/nice triage for all the things currently in the child, related, and referenced-by sections of the sidebar here.

Note to self: next most important tasks are:

1. provide review and direction for #3019490: Provide a Layout Overview dialog that allows performing all actions in a text/form based method. Lots of potential to triage should and nice out to follow-up issues. Concentrate on user task gaps.
2. provide review and direction for #2995689: Allow reordering blocks without a pointer device
3. provide direction, and specimen markup for #2917777: Improvements to the styling, grouping, etc. of the Layout Builder UI actions form

triage done, remove TODO

@andrewmacpherson and I discussed #2917777: Improvements to the styling, grouping, etc. of the Layout Builder UI actions form, which was listed under both "must" and "should"-have. We identified as #3040645: Add a role=region wrapper to the Layout Builder action form to fix screen reader navigation barriers as the most important thing to complete there as it can be considered a major bug, but there is a workaround for it so it's not stable-blocking.

Then the remaining issue #2917777: Improvements to the styling, grouping, etc. of the Layout Builder UI actions form has been rescoped and postponed on #3040645: Add a role=region wrapper to the Layout Builder action form to fix screen reader navigation barriers and the other final stable blockers, so that can build on the other fixes that are outstanding.

Updating the IS to reflect this.

Let's keep #2917777: Improvements to the styling, grouping, etc. of the Layout Builder UI actions form on this list as nice to have. It's eventually where the controls for various "show preview" and "show region names" will live, from other issues here.

Oh, I see #291777 was duplicated in the triage. Doh, setting it back to what @xjm did,

Added #3042107: Layout Builder actions are inconvenient to access via keyboard navigation to "should have"

1. #2995689: Allow reordering blocks without a pointer device landed today! 🎉
2. I added #3041143: Add ARIA group roles to Layout Builder UI directly to the must-haves as the critical part of #3019487: [plan] Describe layout builder UI to assistive technology, and then added the remainder to the should-have section.
3. #3037742: The toggle that makes Contextual Links visible at all times might not be sufficiently discoverable is still open, but I think this issue is not actually a Layout Builder issue. Contextual Links already supports the needed functionality, so I think the issue is therefore a problem with the discoverability of that accessibility feature, and therefore a major bug with Contextual Links itself (so not a stable blocker for Layout Builder). However, I did add that and a couple other contextual links issues to the should-have and nice-to-have lists (including one to discuss whether contextual links are actually still the right choice for those operations).
4. #3019490: Provide a Layout Overview dialog that allows performing all actions in a text/form based method is still open, but it sounds like that's a nice-to-have now that we've fixed the must-haves.

With those updates, I think all the must-haves are complete! Thanks so much to accessibility reviewers for providing detailed feedback on Layout Builder's accessibility throughout the development process, and to the contributors who helped fix these critical bugs in the module.

Promoting to major to accurately reflect the priority of the remaining accessibility work.

I think all the must-haves are complete!

Wow! That's exciting! Congratulations!

Does that mean we can/should remove the "Layout Builder stable blocker" tag from this issue?

Seems that way. Tentatively doing so.

While reviewing the 8.7.0 release notes about Layout Builder I couldn't find anything about a11y. Which I hoped to see since the positioning of it against Gutenberg. So I ended up in this issue, and I just wanted to say thanks for all the hard work Andrew et al. Keep it up!

Linking open issues from the CivicActions Accessibility - VPAT.

I'm removing this, as at this point it is just a plan, right? This isn't a bug (although it refers to bugs).

Right, these are accessibility bugs (some of them major) that still need to be fixed. It would be great to fix them as part of an effort to add Layout Builder to the Standard Profile.

Absolutely @xjm. But each of those bugs probably will have their own issue.

Adding reference to Windows High Contrast Mode.