From the session schedule:

The AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team would like to explore how it can become a shared resource and best support Make Teams and the WordPress project as a whole. The current challenges are that this small team struggles to track where they could be helpful across the WordPress project, and they would like a stronger system that allows them to better address requests as a whole team.

Perspectives needed: Current and interested Accessibility Team members, members from other Make Teams who want to collaborate with Make Accessibility.

Facilitator: Joe Dolson (@joedolson)

Notetaker: david wolfpaw (@wolfpaw)

Notetaker: Taco Verdonschot (@tacoverdo)

Raw Notes:

• we would like to see how we can be a better support for other Make teams, given our extremely limited resources as a small team.
• We are in total the equivalent of one full-time person of hours, supporting all other teams.
• The accessibility team proactively reaches out to other teams, and would like to not do that – one of the biggest consumers of team time is trying to reach out and see what they can do. It’s not about doing more, it’s about being more productive.
• Some other teams would like to switch this around, and see what they can do to proactively reach out to the accessibility team to see what is doable and how they can help. Recognize at what point they should be asking for input to see where they could go wrong with accessibility without proper support and information.
• The accessibility team could help to identify what things teams should be aware of, and the crucial timing
• For other teams: what ways do you interact cross-team that are working already, whether they are formal collaborations or are ad-hoc?
• Successful is always a work in progress. For example, we have help with accessibility with one point person. It is very helpful, but it would be better to have more than one. Having checkpoints on when we could use extra feedback, providing a feedback cycle. Acknowledging as a team that nothing is set in stone, even if we’ve already started moving forward.
• One example of the crossover work with the documentation team is that someone keeps an eye on what is going on in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ to know what Documentation needs to be updated. Similarly, Learning looks to Marketing and Documentation to see what is coming up and knowing what
• Each team should have an accessibility lead, who can liaise with the cross-team Accessibility Team. There is a lack of education for teams to know what things they are doing are not accessible. Having a champion of accessibility on each team would make it easier to have cross-team collaboration.
• Part of the routine, weekly structure of the accessibility team currently is reviewing updates from other teams. It has been hard to get people from other teams to actually do those reports.
• The Documentation team has someone trawl through pull requests and posts from other teams. It is a fairly intensive project that takes a lot of time to do.
• Ideally the person for each team has a basic sense of accessibility, even though they are active on another team. What skills do they need, and is that something easily trainable?
• Some simple things can be easily learned, such as color contrast, font sizing, using extensions that help to manage it, etc would be easy for someone to pick up.
• Content Creators may have the same questions, and the liaison can give them answers to take some of the burden off of the accessibility team.
• Working out what a liaison needs will work wildly different based on the team. It could be a process of discovery between those teams. Something within scope of the accessibility is to have a one-on-one with the liaison, have a discussion, document it, and publish it.
• Real world accessibility at events has other needs, but it is within the team purview. There is a P2P2 P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/. channel and they are working on documenting to setup principles and documentation that can be referred to for every WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more.. Documents will be published from the Community Team.
• By the Accessibility Team doing outreach to other teams it can be seen as critical, as opposed to being helpful. The sooner that the team can get involved, the more that it can be collaborative.
• There is worry that the Accessibility Team is seen as a blocker for growth. It is preferable to have others reach out for feedback, as opposed to being reached out to after things have been published.
• Other teams don’t want to be badgering the Accessibility Team all of the time, so there’s a problem there. It has been tricky to get feedback on some in-progress things. Part of the wordpress.org redesign has been trying to get pages live to get feedback and update, but it has been perceived as being done.
• There could be some sort of flag that pages need review still. The challenge with having a flag is that it will be perceived as a blocker; everything is done except for that review.
• Documentation is confusingly not responsible for all documentation. For instance for handbooks. But the documentation team can provide assistance. By helping the Playground Team it has made it more known throughout the project what needs to be done for accessibility.
• All of the teams could have templates of how to work with cross-teams for things like accessibility.
• Working with the Training Team, trying to work with the Accessibility Team has been difficult.
• There are two questions: what are the difficulties with onboarding people, and what are the difficulties with retaining people. We have so many needs that onboarding is hard to do.
• One of the biggest problems with onboarding is frustration and pushback in trying to get things done for Accessibility.
• There is a concern as to what legal fears exist for attaching our names to teams for doing things relating to Accessibility. For instance, there are overlay companies who have been doing legal battles, and are highly litigious and have a lot of money. These tools do not really work and people have been sued or threatened with lawsuits. Adrian Roselli is being sued currently as a notable example
• If there was a way to obtain support from the WordPress Foundation that there would be support concerning frivolous lawsuits. But that would be a difficult ask to have and unlikely to happen.
• The individual teams could work better at onboarding new people to do accessibility with more redundancy and scaling. This could be done with
• The looping of people together from various teams sounds like it would be a good place for a Working Group. This would go with the most pressing accessibility concerns to start, and then turning that into a Working Group that would go through getting a liaison for the team, working with Documentation, creating onboarding, having the documentation and onboarding live on Learn WordPress, having things where people can step in, do training, and be qualified.
• Individuals will not have the confidence to step into a role of being a liaison without having some formalized training that qualifies them.
• There should be some feedback on how people got interested in being involved in the Accessibility Team from a different team, to determine how to best make people liaisons. The Community Team reached out to see how they could best facilitate to make WordCamp US 2023 more accessible for instance. Community Team has the risk that their accessibility mistakes are often more public, with more people talking about them.
• The Accessibility Team deserves credit for a tone shift into, “How can we help other teams do better?” as opposed to pointing out what has been done wrong.
• An issue is when the Accessibility Team provides feedback, and the feedback is not implemented. When issues are highlighted and no one wants to do anything about it. A reason to stop things from moving forward beyond development/merge is that once it is launched, it is hard to get things resolved for accessibility. Maybe for visual or functionality, but not for accessibility.
• People on teams do too much to move new features apart, making it harder
• How people can help: having a pause window on pushing new features up, but making it better worded that it will sound like . It is hard to see which things are actually moving forward versus which features are just experimental and won’t ever go anywhere. If everything in progress, even basic experimental
• There are security audits that happen automatically that will stop things from moving forward. Why are there not automated and manual checks for accessibility that are not blockers for things moving forward? There are some incredibly basic problems that are not addressed before features go out for review or even to publish.
• Automated testing does have its place. Some of the issues are so basic that the browser automated accessibiilty testing would catch. It would be worthwhile to eliminate a base set of issues by starting to incorporate automated testing, but make it clear that passing that testing does not make it accessible, just saves some time.
• Guternberg, most of the time, is good with micro issues for accessibility interactions. But is on the macro issues that need help. Getting rid of having to look for micro issues will really help.
• The hard part is setting up infrastructure for testing, not writing actual tests
• There is not yet something in Training for general accessibility testing. There is an open issue for something to be vetted.
• The 5 for the Future discussion talked about having companies take on specific projects, which could be a place for a company with focus on accessibility that would be willing to take on this task.
• Having a conversation with MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and Documentation team to work out how to be a liaison for those teams would be a good start. Being able to incorporate more automated testing into Core would help. Teaching people at the best point to reach out to Accessibility Team would help.
• There should be criteria for if something is flat-out a blocker to something launching on the accessibility level. Similar to how there is for things like security issues.
• Some of the basic things that could be solved are having things like checklists for the Community Team that will make sure that basics of accessibility team are covered for events, as well as the websites around them. Informing people who are attending what accessibility means for your event and venue, not just ensuring that they are there.
• A proposal to refer to liaisons as “allies” to the Accessibility Team, ensuring that there will be someone embedded in that specific team that will champion their needs. This is especially relevant to content-heavy teams, such as learning, documentation, training, marketing.
• The need for liaisons could be a specific level of knowledge that is siloed that could be solved by people with the specific, focused knowledge working with the people having issues directly.
• The liaisons and allies don’t have to be one person on each team, but could be a larger number of people to avoid information siloing. It is all coming down, one way or another, to documentation. The Accessibility Team would definitely benefit from help from the Documentation Team.
• Upcoming legislation that will be more and more strict on accessibility. Informing people about what is coming up: is that something that would be considered as a role for the team, since there is no legal team? The Accessibility Team says no, they are not qualified to provide legal advice and could not be the resource for this.
• A rewrite is in progress, but has been in progress for two years, of the Accessibility Team page on make.wordpress.org One of the topics for Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/. is what the statement that the team will be about, but also having accessibility statements for the website itself.
• The commitment to accessibility should be spread across more teams. From a practical standpoint, there is nothing that is, “just the Accessibility Team”. There is always a reason to have subject matter experts, to ensure that different teams do not go in different directions on what we should do.
• Quite a few teams have people that are cross-team active. Given the low resources for the a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team, it’s not feasible to have them in all the other teams.
• A11y team is actively searching for updates from other teams. This is currently happening with a few teams, but not with all of them. 
• What would a liaison-person need as skillset? Is that easily trainable?
• Working out what a liaison needs depends on the team. It would be a process of discovery. A possible feasible offer from the a11y team would be to have 1-on-1 with the potential liaisons. 
• Does the a11y team also extend to in-person events, or is it limited to the WordPress software?
• Yes, but it’s taking a severe toll on the time available to work on the software. 
• What are the challenges to onboarding new people to the a11y team?
• We’re so busy trying to keep up, we don’t have the time to onboard new people. We need people to be coding, we need people to be testing. 
• What are the challenges to retaining people to the a11y team?
• People are getting burned out from the pressure and frustration, due to the slow process and severe pushback. The other reason is Matt Mullenweg, who personally offended many people in the a11y community team. 
• I don’t feel comfortable contributing to the a11y team because of lawsuits happening against a11y experts. 
• [short explanation of what’s happening to Adrian Roselli] 
• Can we form a working group that goes through all the other teams to create a resource on what an a11y liaison should be/do? That way we can create a “personalized” course for each team. 
• One of the challenges is identifying issues that are actually moving forward vs issues that are just experimental and will never go anywhere, and thus don’t need the a11y team’s attention. 
• Is it possible to automatically check for some of the basic things?
• Yes, that would be possible as part of a linting process. But it indeed is very basic, because it would still need a check by a person to verify if -for example- naming is done right.
• Action items
  • Have a conversation with meta and training to find out what a liaison role should look like
  • Have more automated testing
  • Having champions for a11y in different teams

#summit, #summit-2023