It would be really cool to know that all blocks that replicate classic editor functionality are accessible in Gutenberg.

The right thing to do here is to get an independent accessibility audit. WordPress has a stated policy of meeting accessibility guidelines in core, and also has a responsibility to its users to meet those guidelines. Only a thorough accessibility audit can show whether this is the case or not. The accessibility team have flagged numerous issues, some of which have been handled, others which have not. At the very least, these must be addressed.

WordPress is an interface between the publisher, a database, and the visitor. How exactly the publisher chooses to input or manipulate the interface is up to that user. WordPress' job is to make the interface accessible for whatever input modality chosen by that user. This is neither new nor controversial: It is the foundation on which the web stands.

I agree with @mor10. Considering how invested Automattic and the core team has been in the project, and are still seeing issues, the only true and valid path forward is to have an independent, objective audit.

WordPress has a stated policy of meeting accessibility guidelines in core

Yes, exactly. I'd want confidence from the leads in the larger w.org project - such as @afercia and @rianrietveld - in the work here.

In short, I believe Gutenberg _CAN_ be accessible, but I'm concerned it might not be shippable in its current state based on the 117 items open in the project.

Hoping this can happen!

I'd fully support an external, independent accessibility audit.

As you mentioned, there are some perception issues that I think are related to the lack of material and information regarding user testing, and specifically, re-testing as development progressed. Instead of chasing user outcomes, it feels like we are chasing down bugs and regressions.

I appreciate your honesty here, and I agree that an external/independent audit would be valuable. But, I do fear that this is retroactively addressing accessibility from a technical standpoint (i.e., checking the boxes for WCAG 2.x/AA) instead of looking to provide a _better_ experience for those that might not be using a mouse and keyboard. For accessibility alone, qualitative and quantitative research of the Gutenberg experience without data relative to the current experience (or, even better, other similar products) might not tell a fair story.

I think transparency around this information would go a long with community support and ease a lot of friction, both from an accessibility standpoint and the larger Gutenberg rollout.

I'm not surprised to hear others are in favour of an external audit, which would be great to do. 👍 I can tell you I'd love that too, and will be looking into ways we can facilitate that over the next week.

Are there any accessibility-specialising agencies/companies involved with WordPress that would be able to prioritise their time to run through an accessibility audit of the project (probably as of 4.0, which is a big release)? I think it would be handy to establish a baseline sense of how Gutenberg stacks up against the Classic Editor.

I am sure there will be issues (as mentioned above, we have over 100 accessibility issues) but I'm trying to get a macro view of accessibility in Gutenberg. It should be pointed out we have well over 100 issues labelled "bugs" as well, but this is thanks to us considering no bug too small. We try to log everything, but remember this means 100 accessibility issues, not 100 accessibility blocks. The accessibility blockers (as of right now) are contained in the Merge Milestone this issue is a part of.

Thanks to those who have added their voices to support of an audit. I will provide a list of flows we want to test and ensure work for users as an MVP--when I do I'll post them here but I haven't fully formulated them yet.

An external audit is a great idea. I would be happy to contribute financially to hiring a qualified firm to perform this audit.

I would also contribute financially, especially for something of this magnitude and importance.

I would also be willing to lead the way to help raise money from the community.

I like this idea. For enterprises that require WCAG compliance in their software, an audit can go a long way to quelling concerns. Generating a VPAT from an audit may also help uptake in organizations that require it as part of their contract process. See Building Accessibility into Technology Vendor Contracts for related info.

I also support an external, independent accessibility audit. I'll check into my day job's excellent a11y resources and see what they recommend. :)

That’s very kind! But we aren’t looking for financial contributions from community. I’m going to contact some accessibility auditors and see about getting them to run some audits on Gutenberg.

I’ll see what kind of costs and timelines are involved, but if we can get something reasonably priced with a timeline that will work for 5.0 I should be able to get Automattic to cover the cost. 😊

I was a bit unsure of financial support I could provide from Automattic when I posted an earlier comment and I was a bit unclear about expectations from community: sorry about that! I’ve updated the comment and clarified what I wasn’t looking for. Right now I’m going to see about arranging audits, it will take me probably a few days at least to wrangle the quotes! I will report back once I know more 😊

I know this may not be the place to state this, but my company does accessibility audits. So let me know if you want to know more. Although not so active recently, I have been involved with WordPress for a while and have contributed accessibility ideas to Gutenberg as well as other parts of WP. If I'm not independent enough, I work with a trusted partner who has never used WordPress.

@tofumatt I think a request for proposals would be a good way to state exactly what an audit is looking for and give service providers an opportunity to provide a general outline of how they would proceed. Is there a precedent for this type of process at Automattic?

Hello, I am the IT Accessibility Coordinator for NC State University. We use WordPress for our campus websites and as a state institution we are required to follow Section 508 of the Rehabilitation Act of 1973. Because of this, our authoring tools like WordPress have to be accessible for individuals with disabilities.

We have a huge variety of users of WordPress including students, faculty and staff who use WordPress blogs and edit WordPress sites on behalf of their departments of their organizations. All that to say, WordPress must be accessible for these individuals.

As an institution of higher education, we want to stay current with new programs and technologies. It would be detrimental for us to not be able to progress and use Gutenberg or to do a "separate by equal" situation where people with disabilities are limited to using the classic editor while able-bodied people can Gutenberg.

That is so awesome to hear 👍

I totally agree! Of course, I want to set the clear expectation that there may be accessibility issues we discover (or possibly know about) that we are not able to fix before WordPress 5.0 is released.

There are plenty of sites, for plenty of reasons, that will want/need to use the Classic Editor plugin for a limited amount of time while Gutenberg–or outside plugins–are improved. There are probably going to be users who encounter accessibility issues–along with a host of other issues–that necessitate the Classic plugin for a few weeks/months while we improve our software.

I want the future of the WordPress Editor to be awesome and accessible for everyone. My apologies in advance for users who fall through the cracks at first, for whatever reason. But know we will work toward making Gutenberg and WordPress awesome for them too, even if it doesn't happen right away. ❤️

Regarding Audit

Hey all! I'm still a bit new to being a release lead and I'm coming from nearly a decade working on the @mozilla project where we too worked very much in the open, missteps and all. I'll be as transparent as possible about what's happening, including trying to give timely updates (hence my being unsure about being able to pay for accessibility audits until checking with some folks).

The kind of audit I'm looking to do may not be anything too legal/compliance-specific as I am first looking to get a macro sense of the usability of WordPress by users with accessibility needs. If that includes compliance stuff though: awesome.

Right now I've been in touch with some @WordPress Accessibility community members and knowledgable @automattic employees who have provided me with some folks to contact about an Accessibility audit. Right now I want it to be impartial (somewhat outside of the WordPress community is great to avoid bias/past knowledge/etc.), high-level, actionable, and done somewhat quick. I know I'm asking a lot 😆

I have some folks in mind now and will be reaching out to them I have contacted several companies that specialise in accessibility audits. I'll post updates here, but I won't know more until next week. For now, there's:

1. no need to offer financial support (but OMG thank you so much to those who have, that's super cool to see your commitment to WordPress)
2. no need to offer your services (I think we want someone outside the WordPress ecosystem, but if you want to help with regular bugs/accessibility testing please do!)
3. much ❤️ from me 🙂

Have a great weekend, I'll keep you all posted! 😄

If looking for further vendors for the audit, I recommend WebAIM at Utah State University, who is generally considered as one of the top web a11y resources in the United States. Not affiliated with them in any way other than reading their amazing web a11y documentation, but I have seen that they do offer audits.

Although WordPress itself is open source and still has lots of volunteer labor, it's also hit the "big time," as of were, and can no longer afford to fall back on the, "But we're just open source," crutch. I think a full accessibility audit and the commitment to improve where WP is found to be lacking (not just Gutenberg) would be a great source of forward movement when it comes to WP adoption. Plus, of course, democratizing publishing, and all that.

There are plenty of sites, for plenty of reasons, that will want/need to use the Classic Editor plugin for a limited amount of time while Gutenberg–or outside plugins–are improved. There are probably going to be users who encounter accessibility issues–along with a host of other issues–that necessitate the Classic plugin for a few weeks/months while we improve our software.

This sentiment is just unacceptable to me and I hope many others who have internalized the WordPress values...

My apologies in advance for users who fall through the cracks at first, for whatever reason. But know we will work toward making Gutenberg and WordPress awesome for them too, even if it doesn't happen right away. ❤️

What is the upside of pushing through an experience that’s not up to the standards of everything else in Core? Deadlines aren’t arbitrary, but that doesn’t mean you cut corners. At least not according to the WordPress values as I understand them. These values are likely distinct from anything Mozilla had, as a newcomer to the community I encourage you to look into them.

In general the sentiment that mostly-working will be enough creates unnecessary risk for the community, and one must wonder who benefits from that. What is the upside to the Gutenberg project or WordPress? It’s not as if we need the help identifying issues.

Since Automattic will apparently be sponsoring and conceiving parameters for this audit, there’s the potential appearance of bias and that they are scoring their own work. I propose that the greater community proceed with crowdfunding to hire an accessibility specialist for a parallel report from the perspective of actual users. Maybe Automattic can do a technical audit or whatever, but the suggestion that Gutenberg accessibility is “not so bad” has been vehemently disagreed by real experts in this field (to wit, Sina Braham at WordCamp Publishers). Maybe we need something closer to a Mikey test where we get blind users to navigate through the app and say if they’d use it again.

This is what I've been sending out to companies I've been approaching for this work, by the way. It may help other folks involved in Accessibility, I'm not sure. At the very least I'm posting it here for transparency 🙂

Requirements

A series of accessibility tests to be done using the Gutenberg editor on a WordPress website using WP-Admin. These tests should include, at minimum, the following test flows:

Core Publishing Flow

• Create a new post
• Add common content (paragraph, image, list, HTML, and table content; see “Using Blocks” below)
• Publish a post immediately and post is made as intended
• Schedule a post for the future using date picker
• Assign categories and tags to post
• Assign a featured image to a post
• Experiment with other Document-level settings, time-permitting

Using Blocks

These are the top-twenty most used blocks on WordPress.com and should be tested to find any accessibility issues not already filed in our list of accessibility issues:

1. paragraph
2. image
3. heading
4. list
5. gallery
6. quote
7. embed/youtube
8. html
9. separator
10. more
11. cover-image
12. shortcode
13. button
14. table
15. spacer
16. embed
17. block
18. embed/twitter
19. columns
20. code

These blocks should be tested with assistive technologies to ensure there are no blockers to their usage, and that their block-level settings are accessible.

Classic Editor

We should verify that, compared to the Classic Editor, there are not notable regressions with regard to accessibility. Creating a post with the same kind of content one can create in a barebones Classic Editor context should be doable with Gutenberg. Gutenberg having zero regressions in editing experience compared to the Classic Editor is my ultimate goal for saying we can recommend it as the default editing experience for users of assistive technologies.

Assistive Technologies to Consider

Because of the limited timeline available and the prioritisation of actionability over extreme thoroughness, I would prefer the top two-to-three browser+screenreader combinations to be used for testing. Using more if time allows is absolutely accessible, but I would prefer starting with the most-used combinations. From my understanding this is:

• JAWS with Internet Explorer/Edge (Windows)
• NVDA with Firefox (Windows)
• VoiceOver with Safari (MacOS)
• ZoomText

Mobile assistive technology is not a priority for this audit. VoiceOver testing on MacOS should hopefully include some crossover with iOS VoiceOver users. Mobile app usage is presumably more of a focus than web site usage.

Post Report and Issues in the Open

Our expectation is that any generated accessibility report should be posted in the open to the WordPress community and should not require me (or any other Automattician) as a gatekeeper. Issues should be posted with useful context to GitHub, with a focus on issue cause and reproducibility. Solutions or approaches for fixes can be posted if there is time in the scope or if the problem is especially complex.

@davisshaver Hello, and I totally agree with you. A thorough and unbiased audit is critical to ensuring that the maximum level of a11y is adhered to.

Not only is it important to make sure the editor is accessible but that there is also a foundation in place to ensure that modifications to the editor can also easily be made accessible. Obviously we can't enforce what people do on their own, but we can at least provide a foundation for people to implement that is accessible.

@tofumatt Also happy to assist in any way possible. I may have access to some pretty good resources for testing, specifically others with React and a11y experience. There are also some people on my team who specifically work with a11y in their day to day.

@tofumatt Thank you for the update. I have a few follow up questions:

1) Is the plan for the audit to be completed before 5.0 is released?
2) If the audit returns issues, what is the plan for addressing them? Will the 5.0 release be delayed until they are addressed?
3) Are there plans being made for how the project will test for accessibility going forward?

@tofumatt If you want some testing by users with a variety of disabilities/impairments, I've done some work with a company called Hassell Inclusion, and they can organise that sort of testing. They're completely removed from the WordPress community. The company is run by Jonathan Hassell who used to be in charge of accessibility at the BBC.

@tofumatt I am also very concerned about WordPress accessibility and eager to help you succeed. I can have our organization perform a full WCAG-EM compliant accessibility audit to whatever standard level you prefer, including both technical and functional testing, and donate whatever portion of the work you need to fit your budget.

I would think we should be looking at both ATAG and WCAG AA, and perhaps WCAG 2.1 rather than 2.0. We could also provide recommendations and coaching to help you choose the best and most sustainable way to close any gaps discovered.

We are conveniently arms length from your development community, yet know WordPress well for many years. I hold all IAAP certifications and have led dozens of such audits on the WordPress platform, over many years, for both private and public sector. Please check out our bona fides at davidberman.com/about to decide how we can best be of assistance.

Using Blocks

I'm not sure the team going to make the audit should be instructed or have knowledge of what a "block" is, at least not initially. They should be in the same initial condition of users who are going to use Gutenberg for the first time, with no special instructions. In a second phase, when going technical, they will probably already know what a block is 🙂

Core Publishing Flow

The accessibility team agrees the main accessibility issue in Gutenberg is the overall user experience. I'd suggest to expand this part: it shouldn't be limited to the _publihsing_ flow, instead it should include more tasks, typically the ones that require navigating through the UI and jumping through the main sections (top bar, editing area, sidebar, publish panel). This is more related to the general Gutenberg design, rather than technical implementation details on the various components. In fact, accessibility _is_ design.

I'd like to propose a few tasks:

• build a post with a large number of blocks, say 20 as a minimum
• edit one of the paragraphs in the middle of the post
• change its font size and font color, then edit again its content
• add new blocks using the inserters
• insert a link
• insert a mention
• change block type
• change something in the top bar settings and then go back to the block that was edited
• jump to the sidebar, switch to Document / Block settings and then go back to the block that was edited
• edit the post permalink
• make a reusable block
• add and edit an existing reusable block

Assistive Technologies to Consider

@tofumatt I'm a bit surprised you're mentioning only assistive technologies and, specifically, only screen readers. Accessibility evaluations can't be limited to only screen reader testing. Accessibility is a way broader topic and it's not limited to disabilities or impairments. It's about making the web accessible to everyone.

Even if we want to limit accessibility to disabilities and impairments, they're just too many to count. Just to name a few: speech recognition software users, motor disabilities, low vision, cognitive impairments, seizure disorders, alternative input devices, attention deficit hyperactivity disorder, dyslexia, short-term memory loss, etc., etc. What about things that can't be classified as real "disabilities", for example temporary impairments, environmental impairments, ageing?

The human condition is pretty unstable, and I've suggest you to consider _We're all just temporarily abled_.

I'd like to propose a few tasks:

This extended task list seems good and realistic what users needs to do.

As the Accessibility standards for WordPress core state:

All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA.

Therefore, the audit should take that into account. Specific things:

1) All functionality should work as expected when the browser is zoomed 200% ( note, that this may trigger mobile css) 1.4.4
2) All functionality should work as expected only using a keyboard 2.1

It's important for us to remember that what we are looking for here is that everything is usable by all users. It may not be a great experience for some users, that's what version 1 is about but the standards we have are about making sure that it is completely usable. All software ships with bugs and the important thingi is that we know about the bugs and make the tradeoffs of fixing them vs. not fixing them.

Thank you @tofumatt for leading the charge on getting this audit done. I look forward to seeing it happen and for Gutenberg being usable by all.

It was useful, in examining an audit/series of Accessibility tests, to compile a list of "core" Classic Editor functionality that should not regress in the new editor:

1. Creation/editing of paragraph text
2. Creation/editing of heading text
3. Creation/editing of pre-formatted text
4. Creation/editing of bulleted list
5. Creation/editing of numbered list
6. Creation/editing of a quote ("Blockquote")
7. Text alignment for paragraghs and headings
8. Adding, editing, and removal of links from text in paragraphs, headings, and list items
9. Indenting/dedenting lists/list items
10. Bold/Italic/strikethrough of text in paragraphs, headings, and list items
11. Adding a horizontal line/spacer to content
12. Undo/Redo
13. Insertion of WordPress "Read More" comment (Read More Block in Gutenberg)
14. Conversion of paragraph content to list content
15. Conversion of list content to paragraph content

I think that's it, so it's what I've been sending.

My list of accessible technologies was quite minimal, agreed. Part of that is around scoping but part of it was because it was a bit of an incomplete list I hoped to add to with time. I've added ZoomText to that list, and will request it be used for testing as well.

Just reviewed @afercia's task list and I agree: that's a great list. I'll work on including as much as possible from that list in the project. I'm not going to update my original list for now but will post the finalised list of tasks once the audit/tests start. Thanks! 👍

Replying to a few questions

@bamadesigner:

The plan, right now, is to start the audit ASAP and have as much info out before the 5.0 release to address any issues that are found and add context to the release regarding its accessibility. In terms of delaying the release: it depends on the issue, the time to fix it, and its impact. My view is that delaying the release is unlikely, but we should cross that bridge when we come to it; I don't want to speculate.

In terms of plans for accessibility testing going forward: that's a bigger question and one not related to the release or this issue so I won't get into it here. For now I'm a release lead for 5.0 and I'm going to focus there; again: I don't want to speculate. But it's something I'm happy to look into after we catch our breath from WordPress 5.0 😄

@LukePettway

If you have experience doing accessibility tests then it would be great for you to either test Gutenberg or triage existing accessibility issues so we know what is still an issue and what needs focus. Working on any issues in the Merge: Accessibility milestone would also be great.

@tofumatt Thank you for your answers but they are disappointing.

Gutenberg/5.0 should not be released until the audit is complete and any found issues are addressed. Hopefully the audit comes back and says there are only a few issues but the decision should be that the release of 5.0 is dependent upon that finding and the time needed to resolve.

I'm not privy to whatever is driving this November deadline but accessibility is too important. If you launch before you make sure these bases are covered, you are setting a dangerous precedent for the entire community, and the web in general, that accessibility isn't the #1 priority and can wait for later.

WordPress 5.0 is not ready until it’s accessible. No other deadline matters more. Not to mention the fact that it violates core standards for accessibility.

WordPress 5.0 is not ready until it’s accessible.

@bamadesigner speaks the truth.

WordPress's stated goal is to "democratize publishing." That, in a literal sense, means making publishing available to everyone. Accessibility is central to this promise.

I hope it's not an equivocation to say that a goal and a promise are not the same and should not be treated as such. 😄

As mentioned before, I thoroughly welcome any outside contributions on accessibility issues and especially those found in the Merge: Accessibility milestone (
https://github.com/WordPress/gutenberg/milestone/43).

If there are determined to be accessibility-breaking issues upon release, I'm comfortable revisiting @rianrietveld's suggestion in Trac to warn users of assistive technology of the specific issues with Gutenberg and suggesting they use the Classic Editor if Gutenberg will present them with usability issues. I would want to highlight specific, known issues and who they'd affect.

I'm not really sure it'd be my call in any case, but even if it were: I don't view it as a good decision to delay the 5.0 release over accessibility concerns when the Classic Editor exists as a fallback. The aim/main feature of 5.0 is Gutenberg, the new editing experience. I would rather release it for the users who will find it usable (which should include many-but-not-all users of assistive technologies), and accept not everyone can use Gutenberg on Day One. That's already the reality for a great many using incompatible plugins. No one is forcing anyone to use Gutenberg when 5.0 launches 🙂

The Classic Editor exists, but it is not part of WordPress, and that is a crucial item to recognize. Requiring a plug-in to adapt the content management system to be usable is a very questionable solution. It is certainly what I have been suggesting to people; but there are many situations that are not well covered by that situation. Most importantly, it means that only people who have the ability to install plugins have any say in whether or not the site will continue to be as accessible as it is right now. For the scenario where somebody simply updates the site, then authors who need to use the site log-in and are no longer able to publish content, this is inadequate. The classic editor should not be an all-or-nothing option that depends on the generosity of a site admin to ensure that people with disabilities can continue to publish. This is the reason that having the classic editor not be an option available within WordPress core is an accessibility problem.

Super-good point @joedolson, one I hadn't considered–and the callout messaging probably hadn't either. Thanks for that.

I would rather release it for the users who will find it usable (which should include many-but-not-all users of assistive technologies), and accept not everyone can use Gutenberg on Day One.

This is an incredibly sobering comment, and this position is poor design at best and actively ableist at worst. I really hope this isn't the solution.

@tofumatt I appreciate that you're trying to do right and balance a lot of concerns, but I find this incredibly troubling:

I'm not really sure it'd be my call in any case, but even if it were: I don't view it as a good decision to delay the 5.0 release over accessibility concerns when the Classic Editor exists as a fallback. The aim/main feature of 5.0 is Gutenberg, the new editing experience. I would rather release it for the users who will find it usable (which should include many-but-not-all users of assistive technologies), and accept not everyone can use Gutenberg on Day One.

You're telling an already marginalized population of users that you'll get around to making WordPress usable for them... eventually. You see how that's alienating, right?

But maybe the more important set of questions is this:

• Whose call is it to decide if the new editor is officially ready to be merged into core?
• What factors are they considering to make that decision?
• What do we, as a community, need to do to make accessibility central to that decision-making process?

@tofumatt to clarify: the accessibility team hasn't asked to delay the release. The only official request has been to add a notice for users with accessibility needs, inform them there are issues to solve yet, invite them to try Gutenberg but recommend the Classic Editor. The proposal was in https://core.trac.wordpress.org/ticket/44671 which has been closed 🙁

I would rather release it for the users who will find it usable (which should include many-but-not-all users of assistive technologies), and accept not everyone can use Gutenberg on Day One.

Cool, awesome, great ableism here. As @briandeconinck said, you're alienating an entire group of users just because they can't use a keyboard and mouse (or display) properly. Our university has put a lot of work and effort into making our WordPress experience accessible and we're still working on it to this day. To have such a large and important piece of WordPress core potentially launch and be otherwise is extremely disappointing.

@afercia Oh, I totally know that! I certainly didn't mean to imply the Accessibility Team's position was to delay release; some people in the comments here were asking about that is all. I'm really sorry if I misspoke and put that on the team. ❤️

That issue has been closed (partially because it's about the "try" call-out which is going away, maybe there was some miscommunication about its intent), but as mentioned here: I'm okay with implementing its concept of warning users of assistive technologies if Gutenberg isn't going to work for them.

I agree with others in this thread pushing for improved accessibility ahead of 5.0. I would also add that the release of 5.0 will be interpreted as a green light by the rest of the WP ecosystem that Gutenberg is ready for real-world use. At that point we will see an influx of plugins and themes that extend Gutenberg and rely on the standards it puts forth as a blueprint for their own development.

As a developer in the WP ecosystem for several years, I constantly look to WordPress core to ensure that the accessibility, styles, and behavior in my own plugins align with that of core. If 5.0 is released before accessibility issues are addressed, then the WordPress community will be looking to an inaccessible blueprint as a model for their own development. Let's make sure that blueprint meets the standards we've set for everything else that has come before.

@tofumatt Are you suggesting that putting up a warning saying that assistive technologies won't work with Gutenberg is a reasonable solution, given the Core Editor will become a plugin that has to be installed coupled with the fact that the user may or may not have the ability/knowledge to install that plugin? I hope I am misunderstanding this, can you clarify please?

As always, thanks for your time!

The Classic Editor plugin was built as a temporary off-ramp for those not ready to switch to Gutenberg. It is tenous at best, and is quickly going to become a problem for developers who will have to provide solutions for two different editors. The Classic Editor plugin cannot be even a temporary off-ramp for people with accessibility needs because it quite literally serves up an inferior experience based on disability. The minimum requirement for WordPress admin is WCAG 2.0 AA. Anything else, including a plugin to degrade the experience, goes against our own policies. I'm taking a hard line on this because we have rules. We don't ship code that doesn't meet our own conding standards. Accessibility should be no different.

Like many others here, I appreciate the efforts of the community and the people pouring their time and effort into Gutenberg to make it accessible-ready for 5.0. Simply, Gutenberg is not ready because it is not fully accessible. End of story.

Until Gutenberg is accessible it should not be merged into core. The notion to release Gutenberg into core for "those who _can_ use it" is not only shortsighted but awfully exclusionary—I would go so far as to say that this creates (and normalizes) a _seperate but equal_ experience for WordPress users. It's an awful precedent and awfully arrogant.

It is my hope that the community prevails and convinces the core team to withhold releasing 5.0 until it is fully accessible. To that end, an independent audit is a good idea and should be pursued.

This issue was filed to publicise my work on the accessibility audit, to communicate that I'd like it to happen, and to track the sharing of that audit in a blog post. It's not meant as a discussion point around what should be considered a release blocker for WordPress 5.0. I've noted folks' opinions on the matter, and I'll relay them to @m, who is the release lead for WordPress 5.0. My understanding is:

1. I don't have have veto over 5.0 shipping, but even if I did:
2. I'm still not convinced there are sufficient Accessibility issues that prevent a release

If the second point changes, I'll relay that info. I plan to be an advocate, but I don't set the timelines and I also don't have solid data around accessibility. That's the point of the audit: so we can speak from a place of hard data. 🙂

Thanks for all the input, but as this discussion has become quite off-topic from its intended scope, I'm locking this issue's conversation for now. I'll leave it open and post updates surrounding the audit.

There was a bit of extra discussion about this issue on Slack: https://wordpress.slack.com/archives/C02RP4X03/p1539300688000100

I think it was worth addressing here so everyone who has been following the issue thus far can get updated on what's happening. @mor10 also pointed out that he felt there was not a clear communication of results from the audit. It seems there's been a lot of misunderstanding around my communication in this post: my apologies for that. I'll try to answer things best I can right now.

I think a lot of the confusion in the closed ticket stems from a lack of clarity around what happens if/when an audit can’t be completed in time for the release timeline or an audit comes back flagging substantial issues needing to be fixed. Based on your comments it is unclear whether you think:

• a) all issues will be fixed within the current timeline
• b) any issues which can’t be fixed within the deadline will be pushed to 5.0.1
• c) if substantial issues are raised, the timeline will be shifted.

What you’ve said so far _seems_ to indicate only a or b are options, but like I said, it’s unclear. The idea of accessibility being punted to meet a release deadline is what people have been worried about for over a year, and those concerns have not been alleviated.

• @mor10 in Slack (https://wordpress.slack.com/archives/C02RP4X03/p1539303342000100)

Based on the current issues in the Milestone, my goal is to have all issues fixed, but I don't think they all constitute release blockers. I will know better how to triage them closer to final tagging, so I can't add much to that now. For now I think they're a realistic list of issues that are the most important before 5.0

Issues that can't be fixed should be moved to the next WordPress/Gutenberg release, yes.

I don't think there's anything in there currently that warrants delaying the release.

This issue was locked because my goal in creating this issue was:

1. to share my work commissioning an audit
2. to share my work creating a blog post on Make/Accessibility surrounding that post

I appreciate input on how the audit could be conducted and also to hear about issues surrounding my "backup" recommendation of the Classic Editor if Accessibility ends up being a serious issue in Gutenberg. It is worth noting right now there is no report to point to that evaluates Gutenberg and recommends against it on accessibility grounds. I haven't seen it, and no one's linked to one here. The sentiment here is around speculative failures. That sort of language is demotivating to the Gutenberg developers who work hard and see a lack of assumed good intent.

The role of Accessibility Release Lead is new and wanted handed to me last week. At the same time a release date of November 19, 2018 was finalised. My first instinct upon being assigned release lead role was to attempt to spend Automattic's money to create an audit as a sign of our commitment to Accessibility, and to create a concrete sense of the actual issues Gutenberg faces in terms of working with assistive technology. I'm working on a constrained timeline and sharing information as I can and as appropriate, with the caveat that I don't want to publicly evaluate companies I'm in discussion with (I consider that unprofessional) and I have to sort through the procurement side of things with Automattic (that aspect to this audit cannot be public, as far as I know).

I am not the final say in a release. I have cc'd @m on this issue; he is the release lead and he makes the call on delaying the release based on Accessibility issues. It would personally not be my recommendation to delay the release based on the current known issues, even within the milestone.

Yes, there is a bigger issue of accessible design overall, but the development and design teams do consider these issues. I'm concerned, more-so, with things we recognise and test for less because we are largely a team of quite-abled users.

Some folks on Slack have expressed to me their observation that the issue looked like it was soliciting feedback and a broader discussion. That wasn't my intention in filing this issue, but simply to keep everything in the open; since GitHub is chiefly where we work on this project, I figured it'd be the best place to do so. I locked the issue because the discussion, while possibly valid to the project as a whole, was distracting to:

1. the issue at hand (and audit and a blog post with results)
2. the team as a whole who is notified by issue comments

Issue comments should be actionable, discrete, and hopefully provide new information. I felt the comments here failed to deliver on those criteria, so I wanted to restrict the discussion to the issue at hand.

I filed this issue in the milestone because I would like for it to happen for WordPress 5.0. If that's not possible, the sad result is it will have to be moved. I am trying my best to work under a constrained timeline with limited resources. Not to "patches welcome" everyone, but if Accessibility is important to you, I would greatly appreciate it if you directed your attention toward our list of open accessibility issues, especially those in the Milestone: Accessibility list.

I'd like to keep this issue open because I want to track my progress with the audit. If there are other discussions you'd like to have related to Accessibility, the "New Issue" button is always there. I notice while I wrote this comment a new issue was already filed (#10537): that's cool 😄

Thanks all, and have a great Friday. ❤️

@tofumatt Can you update the info about the audit?

First thing's first: I've been speaking to several companies over the past week about conducting an audit, and got proposals back from them.

I'll say that I received quite detailed proposals from:

• Level Access
• Deque Systems

And less detailed but still great responses from:

• The Paciello Group
• Heydon Pickering

They all seemed to know their stuff. I'm not going to share the details of the proposals because I don't think that's appropriate, but I have unfortunate news on the audit front. 😢

For at least the time being, Automattic has decided to forgo conducting an Accessibility audit on Gutenberg. The main reasons being:

1. an audit will not be actionable given our release timeline, because…
2. the audit will not affect release timing, so...
3. it would be more prudent to explore an audit on a less rushed timeline in the future

I'm hopeful we'll explore an audit going forward, but unfortunately it will not happen before the merge proposal and thus I'm closing this issue as a won't fix. I would still like to blog about the state of Gutenberg accessibility, both the good and the bad. We're making some improvements to keyboard navigation, colour contrast, focus behaviour, and date/colour-pickers just this week.

Sorry all for getting hopes up and then failing the community on this one. 😞

Just a quick note to say that I'd love to see this continue, even if it happens after 5.0.
Is there a reason not to leave it open and assign it to a different milestone, or future?

We sure have been on a bit of an emotional rollercoaster lately, haven't we? 🎢

First of all, thank you everyone for the work you do. 💖 I know it sometimes isn't easy to be an accessibility advocate, it can feel like a constant up hill battle. Please know that you're having an impact: from the personal (I've learned a lot about accessibility from the people who make up the WordPress Accessibility team), to the foundational (human-centered design is an essential facet of modern design practices).

I really like the idea of a professional audit, though I don't recall us ever doing one of these in WordPress, certainly not a condition for a release. I'd love to see something like it happen at some point. WordPress has always tried to get most of the way there on accessibility by sticking to common patterns and semantics, with the difference covered by key efforts of volunteers everyone on the Accessibility team doing testing and filing actionable bug reports. Gutenberg's move to being an entirely JavaScript-based application has made it harder to apply those patterns, but we can work together to establish new patterns, a new baseline.

We know that Gutenberg still needs more polishing—which we're doing!—and like everything, it will have issues that we'll continue to iterate on in the months and years ahead. Based on a lot of conversations, it appears that the most critical issues are already filed, many of them are fixed, and we'll continue fixing them as they come up.

There are a bunch of issues that haven't been milestoned yet (thank you especially to everyone who's submitted issues in the last week or so!). It'd be good to see a bug scrub to go through these issues and prioritise them. We can ensure the issues actively preventing people from using Gutenberg are fixed, and then focus on the issues that are about making it easier for people to use.

I've mentioned this before, but it bears repeating: WordPress 5.0 isn't the finish line, it's the starter pistol. Many of us in this thread have been working together on WordPress for years before Gutenberg started, and I hope we'll be working together on WordPress for years to come. We've seen many new features come to WordPress over the years, and none of them have stayed the same as when they were first released. We've come up against challenges that most other projects would write off as being insurmountable, but we've made them work.

WordPress' mission continues to be to democratise publishing. Accessibility is about making things work for people who historically have been incredibly marginalised. These aren't just complimentary, WordPress' mission inherently requires it to be accessible.

What we release in WordPress 5.0 isn't set in stone, we'll continue to fix it, rework it, learn from it, and make it better. Gutenberg is the foundation upon which we can build the next generation of the web, and the potential for improving the accessibility of the entire web is there, too. Every component, every block, every interface should be entirely accessible, and every plugin and theme should ultimately be able to take advantage of that. The Gutenberg generation should provide an accessible experience _by default_. Not only that, the colour contrast checker and the heading hierarchy warnings are good examples of how Gutenberg can make creating accessible content the default behaviour, too.

I've unlocked and re-opened this issue, and milestoned it for the future, but we can easily move it to a closer milestone at a later point. I do have a special request that we all try to stay on topic, and focus on productive conversation. I'd love to see us take what's been started here, and figure out a framework for a quality accessibility audit, something that can expand to cover the scope of Gutenberg phase 2, and beyond. We might not be there yet, but we will be. ❤️

Related #10537.

WordPress 5.0 isn't the finish line, it's the starter pistol.

Ultimately, though, that starter pistol appears to only work for those without differing abilities. A starter pistol works in practice, because the sound is loud enough to create a wake in the air that deaf people can feel, and because it makes a flash/smoke that they can see; it makes a sound for blind people to hear. A starter pistol is accessible to everyone; Gutenberg does not appear to be.

By refusing to even consider pausing Gutenberg's release until after an a11y audit has been performed, you are effectively telling anyone that _physically_ can't use Gutenberg that they don't matter to the WordPress community. That flies in the face of the WordPress community standards, is irresponsible, and, quite frankly, it's embarrassing and dangerous for a product that is so ubiquitous to take that kind of attitude toward so many other communities.

I created the "Needs Accessibility Feedback" label for issues that require someone with accessibility knowledge to chime in, but since there's nothing actionable on this issue I'm removing the label 😄

Nobody is saying anything of the sort, @cgrymala. As I mentioned, a professional accessibility audit has _never_ been a requirement for any feature to be merged in WordPress' history. I'd certainly like to see an audit happen, but writing that a lack of audit is "irresponsible... embarrassing and dangerous" is the kind of hyperbole that gets in the way of constructive dialog.

I'll re-iterate my request from my earlier comment, please stay on topic, and focus on productive conversation.

More to the point, a lack of audit doesn't prevent us from fixing issues. If accessibility is important to you, if you (or someone you know) uses assistive technology, now is an excellent time to be testing and reporting bugs.

@pento, I didn't notice anyone argue that an audit was precedent? That seems like a strawman argument, and based on this thread, precedent simply wasn't the genesis of the audit idea.

The audit was suggested by @tofumatt because there is good reason to believe that Gutenberg is not as accessible as it should be according to WordPress' own standards. Without an independent audit, or even just _A_ audit, why do you expect the community to suddenly believe that Gutenberg is accessible? The lack of an audit isn't irresponsible and dangerous, but this style of decision-making and dictatorial management is.

Given the hurdles of authentication I don’t think that bringing this into core provides benefits for WP beyond what the community gets from the plugin. I don’t believe in its current state the benefit outweighs the cost, and we should err on the side of simplicity.

That's what @m said during the WP API debate. It's yet another example of the hypocrisies evident this recycle cycle, starting with the fact that the "deadlines aren't arbitrary" company refused to set a release date for 5.0, until they found one they liked at which point there was no room for debate. I love Gutenberg and I use it every day. It provides great value as a plugin, and according to Matt's own heuristic we should err on the side of simplicity until it's truly ready.

Accessibility is important to many people on this thread, who have offered time, support, and money to help us navigate this impasse. It is disingenuous for you to suggest that if we really cared, we'd be fixing issues.

Regarding the reasons provided for cancelling the audit:

an audit will not be actionable given our release timeline, because…
the audit will not affect release timing, so...
it would be more prudent to explore an audit on a less rushed timeline in the future

Even if the idea of a 3rd party audit is dead, implicit in the idea of https://github.com/WordPress/gutenberg/issues/10537 would be the auditing of Gutenberg for accessibility means. The fact that Automattic is willing to release Gutenberg to Core with no self-imposed standards for accessibility is extremely problematic. Ultimately I am disheartened to be reminded that at the end of the day, Automattic's interests appear to be promoted above the community's when it comes to the development and release of Gutenberg.

This thread is about:

1. conducting an audit
2. filing issues based on the audit
3. posting its results as a report to the Make/Accessibility blog

We recognise the usefulness of an audit and that folks would like one performed. Please keep comments related to the process of:

1. conducting the audit
2. scoping of the audit
3. results of the audit

I'm hiding off-topic comments that are re-hashing what's been said and highlighting the importance of an audit. I would like to see one conducted. We're all in agreement there. Please keep comments on topic, productive, and make sure they are providing new information/adding to the issue at hand.

@davisshaver Please remember the WordPress etiquette, especially:

Contributions to the WordPress open source project are for the benefit of the WordPress community as a whole, not specific businesses or individuals. All actions taken as a contributor should be made with the best interests of the community in mind.

The WordPress open source project is a volunteer-run community. Even in cases where contributors are sponsored by companies, that time is donated for the benefit of the entire open source community.

While @pento, @tofumatt, @m and others are donated by Automattic, they are working for the betterment of the project. Automattic is not the ones that are deciding when Gutenberg will be released.

Auditing can and will continue as noted by @pento:

now is an excellent time to be testing and reporting bugs.

Anything that can be done to help contribute to that testing and reporting process is beneficial. There are a number of older issues that could use testing to see if they are still an issue that don't require any specialized assistive technology to test. Doing so would be a great assistance and is in part what an independent audit would have provided.

I wasn't aware that being release lead of WordPress.org involved Matt dropping his fiduciary responsibility to Automattic. While you could argue that the conflict is minimal, or that Matt actively works to mitigate the conflict, the WordPress etiquette you quoted is a recommendation and not a description of the world... Ultimately conflict does exist.

I'm sure a lot of people are lurking this topic at the moment and I will say if you are interested and want to help but you haven't used assistive technology before (screen readers) join the discussion over at https://make.wordpress.org/chat/ in the accessibility channel. Feel free to reach out with a DM to me even. You might be surprised at how easy it is to get setup with NVDA/Voice Over/JAWS so that you can start testing things out.

Beyond that there are a lot of tools which are available for testing WCAG requirements:
Chrome aXe:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd

Contrast Checker for WCAG: https://chrome.google.com/webstore/detail/wcag-contrast-checker/plnahcmalebffmaghcpcmpaciebdhgdf?hl=en

Chrome A11y Tools: https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en

There are 113 open issues with the accessibility label that are currently open:
https://github.com/WordPress/gutenberg/labels/Accessibility

Whether we may agree with the current decisions being made or not, I think we can all agree that there is still a lot of work that we can all take part in lending a hand to help solve. Even in an absence of an official audit the community still has the power to help deliver a more accessible experience.

This issue was filed to publicise my work on the accessibility audit, to communicate that I'd like it to happen, and to track the sharing of that audit in a blog post. It's not meant as a discussion point around what should be considered a release blocker for WordPress 5.0. I've noted folks' opinions on the matter, and I'll relay them to @m, who is the release lead for WordPress 5.0. My understanding is:

1. I don't have have veto over 5.0 shipping, but even if I did:

2. I'm still not convinced there are sufficient Accessibility issues that prevent a release

If the second point changes, I'll relay that info. I plan to be an advocate, but I don't set the timelines and I also don't have solid data around accessibility. That's the point of the audit: so we can speak from a place of hard data. 🙂

Thanks for all the input, but as this discussion has become quite off-topic from its intended scope, I'm locking this issue's conversation for now. I'll leave it open and post updates surrounding the audit.

Literally every person with disabilities who has tested Gutenberg, both recently and at the outset, has flagged blocking issues as to why it's not accessible. And user testing is just as important to accessibility as is WCAG 2.0 level AA compliance. Probably should say WCAG 2.1 AA at this point but WCAG 2.0 still gets you a lot closer to where you need to be. Saying that you don't have data isinaccurate at best.

A lack of an audit in this case is irresponsible because, for starters, unlike WordPress in the past, a framework has been chosen that does not come with accessible components out of the box, and unlike with past WordPress, you are heavily modifying the document object model with Gutenberg, as well as removing things from the accessibility tree, and in the case of browsers, the DOM and the accessibility tree are literally how assistive technology retrieves information to interpret. Even if you leave assistive tech out of this, as Gutenberg currently stands, the cognitive load is enormous. The classic editor plugin is a completely unacceptable substitute. For starters, it's site-wide. So if a site's using Gutenberg, and I need to go in and do something with content, I can't do that on a per-user basis, and I can't install the classic editor plugin, do my work, and then uninstall it and expect that everything will behave as it should once the reversion back to Gutenberg takes place. And yes, I've tested this. The fact that accessibility is being left as an afterthought, again, is literally how WordPress got into the mess it was in back in 2011/2012 when the accessibility team first got off the ground. And the project is quite literally making the exact same mistake again, and asking us to trust that it'll eventually get this right, again. I'm sorry, but how many times do people with disabilities have to be sent to the back of the bus for the greater good? How many times to we have to be satisfied with a whole lot of pretty words about accessibility, about how we promise we're going to do better next time, only to find when it comes down to brass tacks that accessibility really isn't a priority?

For at least the time being, Automattic has decided to forgo conducting an Accessibility audit on Gutenberg. The main reasons being:

1. an audit will not be actionable given our release timeline, because…
2. the audit will not affect release timing, so...
3. it would be more prudent to explore an audit on a less rushed timeline in the future

@tofumatt @pento Can you clarify whether the timeline mentioned here refers to a release date of November 19, 2018 or January 22, 2019 as mentioned in the Proposed WordPress 5.0 Scope and Schedule?

The January 22, 2019 date would allow more than three months between today and the release of 5.0 to complete an audit and take action. The reasons above suggest that we cannot get an audit completed and significantly improve accessibility in three months time. If true, that is all the more reason to start the process now and respond to the audit by fixing as many issues as we can before 5.0 releases.

The idea that the timeline will become less rushed after 5.0 (when it's in the hands of real-world users who need it most) makes no sense at all.

Sites that were WCAG 2.0 level AA compliance but new content edited with Gutenberg will not be compliant when 5.0 is released unleashes a legal nightmare.

Thank you everyone who's commented here so far and kept the discussion on topic. I really appreciate it: with so much going on around WordPress 5.0, it really helps me be able to put aside the time that this issue deserves. 🙂

@amandarush: You mentioned several concerns, I'll try to answer them all, but please let me know if I miss anything.

Literally every person with disabilities who has tested Gutenberg, both recently and at the outset, has flagged blocking issues as to why it's not accessible.

I'm truly grateful to everyone who's flagged these issues. I had thought that we'd done a reasonable job of addressing these issues as they came up, but clearly there's more work to do. When @tofumatt has been referring to "not having data", I believe he's looking at it from the perspective that we've fixed a lot of accessibility issues, we don't have a full idea current state of things, so we want to get a clearer picture of the severity of the remaining issues.

A lack of an audit in this case is irresponsible because, for starters, unlike WordPress in the past, a framework has been chosen that does not come with accessible components out of the box

Are you referring to React here? My understanding is that applications built with React are similarly accessible to any other library that dynamically updates the DOM. Provided we make appropriate use of aria-* attributes (as well as ensuring predictable keyboard focussing), that it should be usable with assistive technology. Is this not correct?

The classic editor plugin is a completely unacceptable substitute. For starters, it's site-wide. So if a site's using Gutenberg, and I need to go in and do something with content, I can't do that on a per-user basis, and I can't install the classic editor plugin, do my work, and then uninstall it and expect that everything will behave as it should once the reversion back to Gutenberg takes place.

Thank you for bringing up this use case, it's a good example of where the Classic Editor plugin currently fails. We can certainly add a per-user option.

And the project is quite literally making the exact same mistake again, and asking us to trust that it'll eventually get this right, again. I'm sorry, but how many times do people with disabilities have to be sent to the back of the bus for the greater good? How many times to we have to be satisfied with a whole lot of pretty words about accessibility, about how we promise we're going to do better next time, only to find when it comes down to brass tacks that accessibility really isn't a priority?

I'm sorry. Despite the best intentions of everyone on the Gutenberg team, we haven't done enough. I can honestly say that accessibility _has_ always been a priority, but it hasn't been a _high enough_ priority, and we've done a poor job of communicating where accessibility has been improved. I mentioned some of those improvements in my earlier comment, but those improvements are of no benefit if we haven't hit the baseline accessible experience.

Of course, an apology is no use without actions to make it right, so here's what I'm proposing. Right now, the intention is to prioritise and fix as many accessibility issues as possible. We've fixed hundreds already, and there are fixes already in progress for some of the open issues. We'll be testing, of course, but we do need the experience of people who use assistive technology to uncover bugs. Any testing and bug reporting you're able to make time for is greatly appreciated.

While I believe we can get the block editor to a state where it has an acceptable UX for assistive technology users by the time 5.0 is released, I do recognise there's a possibility we can't. Apart from the per-user setting you suggested, how else can we ensure the Classic Editor plugin is a reasonable option for folks to use until they're happy with the state of the block editor?

I would still like to see an independent accessibility audit happen, but without the rushed timeline of the 5.0 release. That's where this issue can be used to create the framework for a comprehensive audit. As problems are uncovered, they can be fixed in 5.0.x releases, there's certainly no need to wait for 5.1.

@kevinwhoffman: The timeline refers to the Nov 19 (or Nov 27 at the latest) release date. Pushing the release date to January 22 wouldn't give us much extra time: between WCUS (and the preparation required leading up to it), needing to organise a WordPress 4.9.9 release, then folks being on vacation over Christmas and New Year, we might gain an extra two full work weeks by pushing the release date by two months. An extra three months sounds like a generous amount, but it would give us very little actual results, and we'd still need a speedy audit, so we could be working on addressing it in November.

@rcemory: While your comment is kind of off topic, it's worth noting that this discussion is related to the block editor interface itself, not the content that it produces to display on the front end of your site. As with WordPress now, content produced in the block editor is accessible. In many cases, it's more accessible than before, as the block editor does a better job of adding appropriate aria-* labels, it warns when you're using colour combinations that aren't WCAG compliant, or when you're putting heading elements in the wrong order.

The classic editor plugin is a completely unacceptable substitute. For starters, it's site-wide. So if a site's using Gutenberg, and I need to go in and do something with content, I can't do that on a per-user basis, and I can't install the classic editor plugin, do my work, and then uninstall it and expect that everything will behave as it should once the reversion back to Gutenberg takes place.

Thank you for bringing up this use case, it's a good example of where the Classic Editor plugin currently fails. We can certainly add a per-user option.

This would be great but this is a concern that was raised more than a year ago, and wasn't addressed so far. Since in the current state of affairs once a post goes GB it can not be reverted to "plain" and then back to GB again while retaining all the relevant information.
Therefor the plan to have a user based option is just not realistic as it means that editors which opt out of GB will have a hard time editing content created by authors using GB.

The comments from @amandarush are powerful and from the heart. And, I know, based on the past experience of trying to advance accessibility within WordPress.

Since I have been involved in the Accessibility Team there have been 4 (I think) major functionality upgrades in the admin area: Custom menu builder, Media manager, Customiser, and now Gutenberg.

As originally conceived and built all of these components were pretty much (or totally) inaccessible to screen reader users and sighted keyboard users. In my view this is due to accessibility not being thought about at all at the graphic design and UX stages. After the Accessibility Team have cried foul, accessibility improvements have been made to all 4, but the underlying design and UX remain largely the same.

So I share her view that WordPress keeps making the same mistake over and over again. And sadly I share her scepticism when we hear "Accessibility is really important to us". It's very frustrating, and one of the reasons I seldom contribute to WP anymore.

It seems unlikely now that accessibility concerns will halt the push to release WP5.0 in November, which of course is a huge let down after the list of accessibility 'blockers' was first drafted in the spring of this year. And the oft-quoted desire for WP to democratise the web, and the promise not to release any functionality that is not WCAG2.0 compliant.

But I think that an independent accessibility review - involving not just testing for WCAG2.1, but also proper user testing - would be a sensible thing to do now. At least that way we all would know where we stand, and appropriate focus can be given to prioritising and fixing the accessibility defects/issues in future releases.

In response to this from @pento

Are you referring to React here? My understanding is that applications built with React are similarly accessible to any other library that dynamically updates the DOM. Provided we make appropriate use of aria-* attributes (as well as ensuring predictable keyboard focussing), that it should be usable with assistive technology. Is this not correct?

Yes, that's true, but the devs need to understand how to make their components accessible in design, semantics, operation, focus management, and with the correct use of ARIA. Sadly, this seldom happens in my experience.

If/as Automattic goes down the path of an audit, it may be worth not just identifying critical flows / user journeys, but also common widgets to review. If these widgets can be identified and audited alone, they can also form the basis of an accessible pattern library. This can help mitigate accessibility risks as more features are built using those patterns.

it may be worth not just identifying critical flows / user journeys, but also common widgets to review. If these widgets can be identified and audited alone, they can also form the basis of an accessible pattern library. This can help mitigate accessibility risks as more features are built using those patterns.

@aardrian That's an interesting starting point that may already exist that will be required for the audit that we may be able to use now to action on: I haven't seen user journeys for Gutenberg, and that is probably the most obvious starting point to starting to scope said audit.

@karmatosed @jwold - Do you know if said flows/journeys for using Gutenberg already exist? Perhaps a list of "widgets" or "patterns" as described here?

I think while this general thread has a lot of emotion (and I agree Gutenberg must be usable by all and ship when ready) - I'd love to find common ground and next steps. I'd love to shift the conversation places to identifying where we're ready to action.

Said user flow would also give us a task list of places to audit for developers, testers and bug hunters to start dividing up and looking for things to report.

@postphotos , I think @afercia outlined a good set of flows above in https://github.com/WordPress/gutenberg/issues/10318#issuecomment-428957684.

@aardrian Agreed, that's a great place to start! 👍 Thanks for recalling that.

My ask still stands - I'd love to know, beyond that initial critical flow if there's additional work that's already been put into user journeys as it relates to features as it'll help validate the work we're doing here. There may be other items we (this group) might want to add @afercia's initial list, or sequence past an initial audit. 😄

For example, we've not called out the Content Structure feature, undo/redo, etc. or viewing a post, and those tasks we might agree are important and helpful for users to be able to use - the things that we agree make Gutenberg incredibly useful and should be accessible. It'd be great to find consensus actively if we can.

An additional benefit to doing an audit is contribution back to the larger React project. React has its own accessibility issues, and an audit of Gutenberg may well identify both issues and solutions that relate to and can help React core.

Well, this is exciting news: https://make.wordpress.org/core/2018/10/18/regarding-accessibility-in-gutenberg/

Keyboard shortcuts for region and block navigation, slash commands, focusable toolbar and sidebar improvements from improved ARIA landmarks and roles, automated end-to-end tests, and more.

ICYMI: The WPCampus organization is organizing an accessibility audit of Gutenberg.

We have finished our RFP and are now selecting a vendor.

However, as most of you are probably well aware, a professional accessibility audit is a large expense for a small nonprofit like WPCampus.

We’re asking for your help to fund the audit to ensure this vital research is completed.

You can read more about the initiative and make donations on our website: https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

Hi Rachel,

I see you're asking us to donate for the audit.
I'm wondering if you've given any thought to my post to this thread I wrote
a couple months ago, offering to donate accessibility auditing, as this
would entirely solve any gap remaining in funding?
We're trusted by some of the top governments and Fortune 500s in the world
with such projects!

Here's what I posted on October 11 2018:

==========================

@tofumatt https://github.com/tofumatt I am also very concerned about
WordPress accessibility and eager to help you succeed. I can have our
organization perform a full WCAG-EM compliant accessibility audit to
whatever standard level you prefer, including both technical and functional
testing, *and donate whatever portion of the work you need *to fit your
budget.

I would think we should be looking at both ATAG and WCAG AA, and perhaps
WCAG 2.1 rather than 2.0. We could also provide recommendations and
coaching to help you choose the best and most sustainable way to close any
gaps discovered.

We are conveniently arms length from your development community, yet know
WordPress well for many years. I hold all IAAP certifications and have led
dozens of such audits on the WordPress platform, over many years, for both
private and public sector. Please check out our bona fides at

davidberman.com/about to decide how we can best be of assistance.

Thoughts?

• David

On Wed, 28 Nov 2018 at 10:10, Rachel Cherry notifications@github.com
wrote:

ICYMI: The WPCampus organization is organizing an accessibility audit of
Gutenberg.

We have finished our RFP
https://wpcampus.org/2018/10/gutenberg-a11y-audit-rfp/ and are now
selecting a vendor.

However, as most of you are probably well aware, a professional
accessibility audit is a large expense for a small nonprofit like WPCampus.

We’re asking for your help to fund the audit and ensure this vital
research is completed.

You can read more about the initiative and make donations on our website:
https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/WordPress/gutenberg/issues/10318#issuecomment-442480511,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABz4pIgVSgZmWJRL2n3Uy-i8Ov7NXnj1ks5uzqdcgaJpZM4XG_WQ
.

--
David Berman, RGD, FGDC, CPWA
David Berman Communications | [email protected] | @davidberman
+1-613-728-6777 https://dialpad.com/launch?phone=%2B1-613-728-6777 | 340
Selby Avenue, Ottawa K2A 3X6

High Level Advisor, United Nations | Invited Expert, W3C | Ico-D
Sustainability Chair | Carleton U. Access Network chair

Upcoming: Toronto | New Orleans | Montreal | Buenos Aires | Tampa | Tel Aviv
Accessibility course: join us online www.davidberman.com/next

This message may contain proprietary information. Unauthorized
disclosure/copying/distribution of contents prohibited.

@tofumatt , I saw this on Matt Mullenweg's personal blog on 29 November:

Finally, Automattic will be funding an accessibility study of WordPress, Gutenberg, and an evaluation of best practices across the web, to ensure WordPress is fully accessible and setting new standards for the web overall.

As you are an Automattic rep, now that the Automattic audit is back on, can you tell us if this will be separate from the WPCampus audit or will Automattic be funding the WPCampus audit instead?

On the one hand, I hate to see WPCampus have to crowd-fund it. On the other, I like the idea of two audits from two firms to compare and contrast.

Matt responded to my question on his blog:

I think it’s fine having two as well, I’ll talk to Rachel about how the funding is going.

For those following along, have committed to fully fund whatever Rachel's project needs on the WP Campus side, and in the vendor selection phase for the Automattic-sponsored one. The latter's goal is to also see what are the best practice accessibility approaches for other block editor style interfaces across the modern web.

@m Thanks for the update. It is very encouraging to see this moving along and I really can't wait to see where it leads. I would love for WordPress to one day be the example of how accessibility should be treated.

@m

For those following along, have committed to fully fund whatever Rachel's project needs on the WP Campus side

This is great and valuable. Is there any reason you don't just fund it in total, today? It seems weird to ask people to keep donating when they know it will be completely funded regardless.

@aardrian That's not in the spirit of what we're doing. We want this to be a community project and to allow people and organizations the opportunity to participate and show support, if they're able.

In late 2018, WPCampus released a request for proposals to conduct an accessibility audit of the WordPress block editor, also known as Gutenberg. In early 2019, we announced our selection of Tenon, LLC to conduct the audit, at a cost of $31,200.

Today, we’re excited to release Tenon’s report on the accessibility of the new editor.

See more at https://wpcampus.org/2019/05/gutenberg-audit-results/

I think it concludes this issue 🎉🎉🎉🎉🎉

All reported issues are tracked under this project:
https://github.com/WordPress/gutenberg/projects/25

All reported issues are tracked under this project

Not entirely correct. The WPCampus/Tenon report includes additional important considerations that are not covered in the list of issues on GitHub. More specifically, the Executive Summary and the Usability Report show (with data) there are broader structural accessibility issues in Gutenberg that can't be addressed in small, actionable, GitHub issues and require solutions at a higher level instead.

This is to make clear that even if all the reported issues were solved, there will be important accessibility issues still to solve. These are typically related to the general design of the editor.

For reference, I'm attaching here two of the documents published on https://wpcampus.org/2019/05/gutenberg-audit-results/

Summary document describing Tenon’s usability testing
Gutenberg_UX_Report.pdf

Executive Summary
Gutenberg_Executive_Summary.pdf

I suggest opening a new issue, or even project, to handle the usability issues uncovered in the report.