Update on Gutenberg accessibility audit

Presenter: I will present an update on the progress made on the Gutenberg Accessibility Audit. This is very up to the minute. It will line us up with July 27, 2020. If you see things that are not quite what you remember, that might be why. I am Joe Dolson. You can view these slides right now as we are going. There is the WPCampus website as well. I want to give a special thanks to Andrea Fercia. This presentation is based on WordPress as of July 27th. There was a release yesterday and it is scheduled for a new release on August 11th. We are not expecting any big changes but a revision can happen at any time. This is as up to date as we can possibly make it at this time.

Here is a quick overview. Our goal is to improve on this where it is practical. We have discussed moving to Y2K1 but we have not yet. We intended to switch but in the rush to get other things done, we never had that conversation. We started with issues and following the report, he generously gave his time to adding that information to our repository so we had this reference. Nine additional pieces were added by the WordPress development team. This is usually because we were splitting apart existing issues or issues were broader and we wanted to apply to it more items. We quickly closed 34 of those because we were moving up to Track. Track is the management system we use for all the core bugs which is separate from Gutenberg issues are tracked. As part of this issue, the team had the media management. It is not part of Gutenberg but it is imported as a means to manage the media there. That was a core issue. At this time, the 99 total tickets opened and 66 of them have been closed and 33 of them are still to do.

As you can see, progress has been made. We have managed to close 2/3 of the tickets. That is a good start. It is 15 months of work to close 66 tickets. It doesn\'t seem like a lot but I will go into detail about what has taken too long and what our successes has been and where we have had some challenges in the process.

How have we progressed and where have we been successful in this? If you want to follow the progress along, there is a project in GitHub in the Gutenberg repository where we are tracking everything that came out of the WPCampus audit. There is a keyword on track as well. We have can always take a look at where things stand towards our progress on these goals. These trackers are specifically focused on what has come out on the audit. There has been some great success that has come out of this.

GitHub makes things centered and left aligned. Whatever you are trying to do, it was in this tool bar. It was scrollable. For some complex toolbars, it was extremely challenging. As part of this development, it has now been remodeled so it follows the ARIA toolbar pattern and this is updated and follows predictable known patterns. This is a huge win and change that has been very successful. Another big change was the observation in Gutenberg of the large number of cases where focus was not visible in high contrast modes. This spawned a large number of tickets. It was something that hadn\'t been looked at in detail in the admin anywhere. While this is not finished, there is still a lot to do and examine. We have managed to do a significant amount of work globally auditing to make sure visible elements are there. This is one where this audit went beyond Gutenberg and we were able to apply it globally.

One thing that got audited was the media manager. This is something that has been a thorn in the accessibility team for years. It has been an area that needed a lot of work and careful attention. One of its major barriers is the fact that it is the one piece of WordPress that was written in back mode. We had a small amount of knowledge of how it worked. There was effort in documenting the media manager, and making a lot of fixes. These are still ongoing. There are changes to be made. Some of them have barriers posing challenges in the process of building the application. A lot of progress is moving forward and it has improved significantly. There were 34 issues originally moved over to the tracker and we have only eight open now. There are a lot of discreet changes that have been made.

We are trying to make the icons more consistent, eliminating invisible buttons and proving high contrast, eliminating breakages including enlarged font sizes so people can work with it better, changing the reading order so it is the same as the visual order, labeling fields better, and improving the live search so it announces that it does something and exposing the messages to assisted technology. This is just a subset of changes. There is still a lot of big changes left to be done.

Among these is the replacement of infinite scroll. This needs to happen throughout the workmans admin. It was finished for WordPress 5.5 but it is not able to be released. That is an example of types of reasons and barriers that have prevented us in resolving some issues. When I go through that, I will talk about why infinite scroll is not finished.

Then there is the various forms of UI characteristics deeply built into how the media manager works and has posed challenges in figuring out how to work them all out together. That is a big process that needs to move forward.

This was a big challenge in trying to figure out where we are in terms of working through the accessibility audit. Just because an issue has been closed does not mean it is finished. Sometimes issues are closed for other reasons.

As an example, we have the GitHub issue 35.14. This issue was on keyboard navigation. It is a big issue in GitHub. There were six examples of keyboard navigation built into Gutenberg. We have addressed all six examples and they have each been resolved. Because of that, the issue was closed. However, the overall topic spawned a large group of issues that we have expanded out from this and it is labeled as keyboard focused issues in Gutenberg. We are trying to pin all the missing pieces. There are thirty issues that are open that came out of this one.

I don\'t want to dismiss the fact that a huge amount of work was done in getting this progress moved forward. Those six examples that we resolved were six structural efforts that got massively revamped to make them work effectively. But, they drew attention to a number of other various issues we need to keep working towards.

Another thing is the table block meta data. The table block in Gutenberg is one of the ones that released in the original release in a very very poor state. It had no ability to define any kind of header cell or real meta data and make it a data table yet it was not labeled as being presentational either. When Tim and I got this, they caused for a scope of remediation to fix it. Those specific items were fixed and the table block can be made reasonably accessible now. However, the scope of the ticket was limited and now there is a new issue just trying to expand it so it is more flexible. Even as it is now, while you can make an accessible table out of it, you can only do that if your data is structured such that it only requires headers in the top row, it can\'t support a column of header cells, the captions are not done correctly, and you actually can\'t create a table labeled as presentational. That is a big limitation.

Give me one moment.

This one was closed because we felt it was separate and discreet issues and it got closed in favor of those issues. None of them have been solved. That made it difficult in sheer numbers to get a scope of work that has been performed. These are important issues. These video captions are a major failure to achieve right now. The reason is that we currently have literally no way to add captions to a video file using Gutenberg. There is no way to do it. You have to actually switch to classic editor to make that happen. That is a problem of deciding what the UI needs to be. We hope to be able to solve that soon. We do need people to dive in and help work on it.

Overall, there has been a lot of success on the expansion of scope of the issues raised in the Gutenberg accessibility audit. It has allowed us to spread out and focus on high contrast mode, effect color contrast and the changing reader order, and using better labels for our fields and better keyboard focused handling as well as the elimination of the worst infinite scroll. These are not all finished but it is a huge success to take that data and apply it on a broader level of the overall site.

There are a lot of big issues still not solved. We have challenges ahead us we need to keep moving forward and thinking about. Some of these are inherent on the goals we are trying to achieve. Some are technical issues. We will talk through some of the challenges we have had to work through.

Firstly, our goal is to meet WCAG 2.0 level AA. They assume specific classes of issues. To make an assumption that your form fields are traditional can be an issue. Any access that is not defined in the WordPress accessibility guidelines is hard to pin down and hard to present data about and hard to defined. The Gutenberg developers are creative. These issues do creep up a lot. One example is in WordPress 5.5 there is a redesign of the block mover or the tool that allows you to move the block from one location to another in your document. As of WordPress 5.4 it was on the side of the block. It had two separate controls. There was a drag and drop with two arrows to move up or down and a block switcher. They have been moved from here and are now on the top bar. That change is reasonable. There are good arguments for why it happened. Those changes needed to happen because of issues related to having multiple blocks next to each other in a layout. The need for a redesign was real.

But those two controls were combined into one. Now the block switcher and the block dragging tool and the arrows up and down look like one tool. This single visual service is serving three separate services. You click it to change the block type, you click and hold it to drag it somewhere or you click on the arrows part of it to move it up down, or not pictured, right or left. This is still being redesigned and I hope the final design for WordPress 5.5 has changed.

It is a concern and the WCAG rules are struggling to capture it. The very fact that a single tool is serving several purposes makes it challenging to work through. Another example was that the block inserter has been refactored in WordPress 5.5. In 5.4, it was a modal. It was all accessible and it was fine and it had been worked through quite thoroughly. In WordPress 5.5, it is no longer a modal or constrains tabbing. It pushes the content to the right to avoid overlapping it. The blocks are no longer grouped in collapsible sections. They are now listed out individually. There is no clear technical reason why this is an accessibility problem. The blocks can be used and tabbed through. There are some significant issues with the fact that there are 70 blocks. If you need to use your keyboard to get to the last block, it is a very long process. If it were a modal you could reverse tab. But this is a change that it doesn\'t technically change any accessibility issues. You can still skip through it and navigate it in multiple ways. But it is much more difficult to use. We are trying to argue against some of the aspects of those changes and trying to figure out a better way forward.

We are constantly fighting regressions. This has to do with the fact that Gutenberg and act and react. There are aspects to changes. Those changes can be unpredictable and have major breakages caused by something that seems to be minor. In WordPress 5.3, the use of drop down menus in Gutenberg broke in safari in voiceover. This was very difficult to pin down. It was reported in November and it took months to figure out what was going on. What was happening that as you navigated through it, some elements behaved differently than others. Eventually it was noticed that it was a specific problem in menu check box and radio. There was a default being run and it was only executing drop down menu changes. In the end it was a simple change and easy to fix but it should have been caught far sooner. If at the time it had been tested in both safari voice over and other voiceover tools we would have known that it caused this problem and we can nail down the change much more quickly. It should not have taken eight months to resolve that change.

We are fighting regression because of constant design changes. These happen for good reasons on many occasions. The need to update the design as WordPress slowly moves towards the new phases on Gutenberg is important. It needs to adjust to fit the new features being developed but it does mean a design is imposed and we discover it and have to completely retest it. It might be completely different. It won\'t be just a new skin on the interface. There will be structural changes we need to explore and identify. This tendency to replace interfaces or restructure and redesign interfaces like the block mover and changer and add new field designs and features and creating a constant need to revisit things that have already been solved. That is a challenge. Some of that is essential because of constant changes to the system.

However, there are systems that really need to be put into place to monitor to this daily and test things constantly so we are not constantly coming back to it and rebuilding from scratch once we discovered something changed.

There is developer resistance. There can be topics that we as accessibility specialists on the team consider to have them solved and consider to be obvious concerns. It can be frustrating when they suddenly disappear. One of these is the disappearance of the focus on a block. For those of us on the accessibility team, they agreed with us and they implemented the change we asked for. Then suddenly we discovered it was gone. The argument was that we didn\'t need it anymore because people now understand the interface. I think that is ludicrous. There is never an argument that people understand an interface that is constantly changing. There is a constant need to try to track things like visible labeling and the need for independent block fields. There are tons of blocks that have multiple parts like the citation has a separate field, or images that have an image and caption. Those secondary fields are typically only indicated by face holders. They are faint and hard to see. They are hard to find and recognize as present. This is partially an argument between making the visual of the editor look as much like the outcome as possible. Partially an unwillingness to accept that the editing experience has to be and is essentially different from the published experience.

There is a lack of structure to oversight. This mostly effects us in the accessibility team because there is a lack of any real leadership role that looks like the WordPress designed holistically. Each piece develops independently and each time there is a new feature added, there is a good chance it has a whole new design. It creates a lot of burden for the accessibility team since there are so many unique aspects to explore. We are looking at the Gutenberg aspect. It uses different guidelines, expectations and colors. This also happened with the site health check. The customizer was a new thing. The themes page used a different design. The media views used a different design as well. Every time a new design comes in we have to look at it as something extra we need to explore.

Finally, there are implementation changes and real technical reasons why we have to actually wait until other things are resolved before we can fix the problem. One of the part of that is revealing blocker tendencies. The infinite scroll was a part of this. The collection of media items is not the same if you are looking at it in gallery view. The infinite scroll changes what you see and get. It caused it to be unpredictable and undependable. We need to fix the consistency. We didn\'t discover it until it was too late.

There is backwards compatibility issues for plug ins and themes. This is a constant issue. If a plug in or theme is using a feature, we need to make sure that when we are making a change we can document it effectively and make sure it can be changed easily or that it won\'t have an obvious change that changes the plug in or theme. It is great we can change themes on the fly but it doesn\'t help us if we have broken it for other people in the process.

There is one epic issue about how we handle all text assignment. Right now one version of all text is stored in the database and it is automatically inserted when you add an image to your post. That is likely to frequently cause bad all text. If your frequent image is used on your single post page as a header, maybe it doesn\'t need anything. But if on the same site that feature image is used on the home page as a link to the page, then it has a new need for all text in that context. We are trying to explore what we can do in that model. There is a lot of work to get there.

I don\'t think anybody here would be surprised that there is technical debt in WordPress. If you are surprised, then I have nothing to say. There is technical debt. The issue, part of the Gutenberg audit, demonstrates an automatic process. It is a well known and documented thing to avoid to do automatic changes of context when you change the value of a control. This particular control was a radio button. It should not be doing that. There is a technical reason. WordPress has both published and unpublished status. Private is an unpublished status. Rather than just change the status, it confirms with you whether you really want to do this and it will publish your post. That is a technical thing that needs to be resolved before this is changed. It wasn\'t a problem in the classic editor. The classic editor only changed when you hit save so you had knowledge of when the change happened. Gutenberg saves things in the background so it will auto publish if you don\'t have a way of definitively stopping that action.

There is a lot to do and many things to handle. Speech recognition is a huge issue. Addressing color contrast seems simple. But there is so many unique pairings of colors and designs it is challenging to figure out which design changes you will make. That has been in the process for some time.

In summary, before I take questions, there is major work remaining. Some of the issues like eliminating infinite scroll throughout WordPress and moving backwards compatibility for plug ins and themes, adding support for video captions, improving shortcuts, allowing user scope, and in general an ongoing status change are all big issues that need to be tackled.

Did the audit achieve its goal? I can\'t answer that directly. But I can talk about what it did achieve and didn\'t achieve. It definitely increased accessibility issues. There is a lot more attention in WordPress development and Gutenberg development than there was prior to the audit. It provided focus to drive tracking and creation of new issues and tickets. It caused us to assess issues we may not have otherwise had time to get to. It saved time to the accessibility team because some of the groundwork was already done. The overall accessibility of Gutenberg has vastly improved today over what it was at its original release.

Still, only 2/3 of the issues raised have been solved. That is a long way before it is fixed. The audit didn\'t solve the satisfaction of how we define accessibility for WordPress.

Key features like adding video captions are not possible without editing the code directly. There is still a heavy dependence on placeholders and icon controls. This effects a lot of people with various disabilities that have not been resolved. We are still looking forward, but we are hoping to get there.

If you have any questions, I will answer them on the Watch page and I will try to get to anything here live, and if I can\'t get to it live, I will try to get to it after the talk.

Room Host: I will try to get through as many questions as I can in the time you have left.

Is there data on how many overall tickets exist now? I imagine the number of tickets is very different after all the other tickets have been added, original tickets were closed and so on.

Presenter: Yes, well the number of tickets I was talking at at the beginning of the presentation were specifically raised from the adit. I could come up with a number for you with the accessibility tickets open. It is in the several hundreds. It is very difficult to do the kind of archaeology to figure out which ones connect or were inspired by things that came from the Gutenberg audit. Obviously, many of those tickets were raised coming from versions of the software never tested by Tennen. Many issues were raised prior to the audit. This is an ongoing process. I don\'t have an answer for you in terms of the audit to talk about how many tickets relate to that. I can say how many came from it directly. The secondary number would be hard to extrapolate.

Room Host: Thank you very much. Are there any accessibility experts involved in the designs or redesigns you mentioned? It seemed like they were breaking up things that weren\'t originally a problem.

Presenter: So, involved is a difficult word when it comes to things like WordPress development in general. There are frequently people involved at various stages. Because the nature of the development is very independently driven, and in all honesty, it is economically driven. The people who can contribute are basically the people who have either enough personal resources that they can contribute their time for free, or people paid to contribute. The amount of time that anyone can contribute at any given time is hugely variable. I don\'t know the background of exactly how each individual piece was developed. What I can say is that we as members of the accessibility team try to identify as soon as we can. It is not uncommon for something to come to our attention when it is finished, and that can be because there is so much monitoring to do. We are monitoring so many things and it is an enormous task. We don\'t have the resources or people to keep up with anything. I think I would say that there is not reliably an accessibility expert involved in everything. There is certainly no accessibility expert involved as a matter of process or requirement since there is no real structure on how it develops. It is all independently generated and people work on what they have time and interest to work on.

Room Host: Great. Thank you. There is a similar question that another attendee asked. The question was, why hasn\'t the Gutenberg accessibility team tried partnering with groups that oversee WCAG to find issues being debated?

Presenter: We are in frequent conversations with people from WCAG. They are also managing projects and they have an enormous thing to do. It is not so simple as just saying, can you advise us on this? Realistically, accessibility is not a fully objective world. There is a lot of subjectivity in trying to figure out what these rules mean. Having participated in standard development for things like WCAG, there are a lot of debate before things are finalized about what our actual goal is and what these things mean. We can\'t demand anything. We can\'t expect anybody to give a specific answer. I know Wilco [sp?] has joined in on a couple things on occasion. I can\'t remember everybody who has talked at any given time. I hope that answers the question.

Room Host: Thank you, Joe. We are out of time. There are a couple more questions in the chat. You can follow up on the website for that. Thank you so much for this session, Joe.

Presenter: Absolutely. Thank you for having me.