tofumatt
commented
6 years ago It would be really cool to know that all blocks that replicate classic editor functionality are accessible in Gutenberg.
Closed tofumatt closed 5 years ago
tofumatt
commented
6 years ago It would be really cool to know that all blocks that replicate classic editor functionality are accessible in Gutenberg.
mor10
commented
6 years ago 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.
bamadesigner
commented
6 years ago 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.
postphotos
commented
6 years ago 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!
rianrietveld
commented
6 years ago I'd fully support an external, independent accessibility audit.
nic-bertino
commented
6 years ago 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.
tofumatt
commented
6 years ago 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.
Shelob9
commented
6 years ago An external audit is a great idea. I would be happy to contribute financially to hiring a qualified firm to perform this audit.
bamadesigner
commented
6 years ago 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.
aardrian
commented
6 years ago 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.
logoscreative
commented
6 years ago I also support an external, independent accessibility audit. I'll check into my day job's excellent a11y resources and see what they recommend. :)
tofumatt
commented
6 years ago 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. 😊
tofumatt
commented
6 years ago 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 😊
grahamarmfield
commented
6 years ago 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.
nic-bertino
commented
6 years ago @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?
CTenan
commented
6 years ago 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.
tofumatt
commented
6 years ago 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. ❤️
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:
Have a great weekend, I'll keep you all posted! 😄
LakenH
commented
6 years ago 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.
sbrinley
commented
6 years ago 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.
davisshaver
commented
6 years ago 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.
davisshaver
commented
6 years ago 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.
tofumatt
commented
6 years ago 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 🙂
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:
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:
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.
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.
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:
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.
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.
Luciaisacomputer
commented
6 years ago @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.
bamadesigner
commented
6 years ago @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?
grahamarmfield
commented
6 years ago @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.
davidberman
commented
6 years ago @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.
afercia
commented
6 years ago 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:
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.
samikeijonen
commented
6 years ago I'd like to propose a few tasks:
This extended task list seems good and realistic what users needs to do.
aaronjorbin
commented
6 years ago 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.
tofumatt
commented
6 years ago 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:
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.
tofumatt
commented
6 years ago 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! 👍
tofumatt
commented
6 years ago @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.
bamadesigner
commented
6 years ago @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.
mor10
commented
6 years ago 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.
tofumatt
commented
6 years ago 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 🙂
joedolson
commented
6 years ago 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.
tofumatt
commented
6 years ago Super-good point @joedolson, one I hadn't considered–and the callout messaging probably hadn't either. Thanks for that.
nic-bertino
commented
6 years ago 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.
briandeconinck
commented
6 years ago @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:
afercia
commented
6 years ago @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 🙁
zachflauaus
commented
6 years ago 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.
tofumatt
commented
6 years ago @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.
kevinwhoffman
commented
6 years ago 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.
kevinpmiller
commented
6 years ago @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!
mor10
commented
6 years ago 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.
digisavvy
commented
6 years ago 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.
tofumatt
commented
6 years ago 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:
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.
tofumatt
commented
6 years ago 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.
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:
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:
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. ❤️
samikeijonen
commented
6 years ago @tofumatt Can you update the info about the audit?
tofumatt
commented
6 years ago 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:
And less detailed but still great responses from:
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:
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. 😞
Right now there is a perception that Gutenberg is quite inaccessible, both in general and compared to the Classic Editor. Below is more/less a copy+pasted comment I made in a recent Make Post about 5.0:
It should be pointed out that the existing (Classic) editor doesn’t include many components for plugin developers extending the editor. The core editor in WordPress is accessible by virtue of being quite basic (it's essentially a
<textarea>), but it’s also at the mercy of plugin developers to ensure their code is accessible. This means the difference between a WordPress editor without and with plugins is wildly different–this should be less true for a Gutenberg install with 5 or 500 blocks.Core Gutenberg components and blocks are built with accessibility in mind, and block author will be able to use these components in their own blocks and get a lot of accessibility built-in to their blocks for free. This is a big win for accessibility of the editor after it’s been extended at all.
There are certainly aspects (often third-party code like colour or date pickers) that are not accessible, though we’ve been working to improve those when there are better solutions.
The Classic Editor and Gutenberg’s editor aren’t an apples-to-apples comparison; one is extremely basic and one is very full-featured. I expect the latter to require more work to make fully accessible, but as we work toward that (and identify bugs), we can provide all users with a better experience.
I think there's a notion of Gutenberg being inaccessible because of older accessibility audits that identified a lot of issues in the very early versions. Things have changed a lot since the early days, and when the plugin was labeled "1.0" it was hardly a ready-to-ship product. I worry that many of those sentiments haven't been re-examined and updated, so there is a prevailing idea that Gutenberg is not accessible or is entirely less accessible than the Classic Editor.
What I'd venture is that Gutenberg is selectively less accessible, but overall more accessible feature-for-feature. Something like a date picker or a certain interaction being inaccessible does not make the entire editor inaccessible. Feature-for-feature, compared to a classic editor with similar capabilities (eg a bunch of plugins installed), I'd bet Gutenberg is more* accessible.
Anyway, I would like to see about doing a new round of accessibility testing with community a11y folks (and see about accessing some Automattic resources to help with it as well).
After that it'd be cool to do a blog post with data that could show Gutenberg's current state of accessibility. It'd be neat to highlight the built-in accessibility features that third-party blocks get for free as well, to show how blocks beat old editor plugins for built-in accessibility.
Inspired by: https://wordpress.slack.com/archives/C02RQBWTW/p1538599045000200