Title: accessibility – WordPress Community Summit --- # Tag Archives: accessibility [ ](https://profiles.wordpress.org/westonruter/) [Weston Ruter](https://profiles.wordpress.org/westonruter/) 7:12 pm _on_ August 22, 2023 Tags: accessibility, [summit ( 24 )](https://make.wordpress.org/summit/tag/summit/), [summit-2023 ( 25 )](https://make.wordpress.org/summit/tag/summit-2023/)    # 󠀁[Community Summit Discussion Notes: Accessibility in the WordPress Project](https://make.wordpress.org/summit/2023/08/22/community-summit-discussion-notes-accessibility-in-the-wordpress-project/)󠁿 From the [schedule session](https://communitysummit.wordcamp.org/2023/session/accessibility-in-the-wordpress-project/): > How can WordPress adopt an accessible-first approach, and what would this mean > for project development and decision-making? This discussion will center on 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) considerations in developing > WordPress software and current friction points, and explore possible solutions > and practices to incorporate. > **Perspectives needed:** Current and interested accessibility advocates, people > interested in or currently involved in release cycles. **Facilitator**: Joe Simpson, Jr ([@joesimpsonjr](https://profiles.wordpress.org/joesimpsonjr/)) **Notetaker 1**: Weston Ruter ([@westonruter](https://profiles.wordpress.org/westonruter/)) **Notetaker 2**: Daniel Bachhuber ([@danielbachhuber](https://profiles.wordpress.org/danielbachhuber/)) [Continue reading →](https://make.wordpress.org/summit/2023/08/22/community-summit-discussion-notes-accessibility-in-the-wordpress-project/#more-2169) [#accessibility](https://make.wordpress.org/summit/tag/accessibility/), [#summit](https://make.wordpress.org/summit/tag/summit/), [#summit-2023](https://make.wordpress.org/summit/tag/summit-2023/) * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsummit%2F2023%2F08%2F22%2Fcommunity-summit-discussion-notes-accessibility-in-the-wordpress-project%2F%23respond&locale=en_US) [ ](https://profiles.wordpress.org/rianrietveld/) [Rian Rietveld](https://profiles.wordpress.org/rianrietveld/) 3:42 pm _on_ July 31, 2017 Tags: accessibility, [summit 2017 ( 5 )](https://make.wordpress.org/summit/tag/summit-2017/) # 󠀁[Accessibility Team Community Summit Notes](https://make.wordpress.org/summit/2017/07/31/accessibility-team-community-summit-notes/)󠁿 ## Review and update 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) coding Standards Considering the shift towards JS-based interfaces, we should consider to review and update the accessibility coding Standards. ### Announcing dynamic content We have: * [wp.a11y.speak()](https://make.wordpress.org/accessibility/2015/04/15/let-wordpress-speak-new-in-wordpress-4-2/) * a  non WP dependant solution: [a11y-speak()](https://github.com/Yoast/a11y-speak) For complex interaction wp.a11y.speak() may not be the best solution. When in doubt discuss solutions with 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. ### Resources * Accessibility handbook has not enough recourses * How to handle ARIA for screen readers * Fact is that traditional web apps reload gives feedback, that JS only apps can not provide. Are there tools we can leverage to help standards adoption? * JS interfaces still should be build with semantic HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. * ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. [https://reactjs.org](https://reactjs.org/) tends to use divs, but that’s not React itself, that’s bad programming * 10UP now released a [complete library for WP](https://10up.github.io/Engineering-Best-Practices/). It’s in GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. [https://github.com/](https://github.com/), so this is expandable * For the handbook we should refer to existing libs or someone to build them * There is a need for good information and components that are accessible ### Workflow Important: The a11y team needs to do more teaching and sharing, instead of fixing things themselves. Specifications within accessibility tickets should contain code examples * We should share accessible components * Is it possible to abstract cases and give examples of good practices * Part of the standard tooling should be testing software react/axe * Give 10 point list of things to check * We should publish about for example audio feedback, focus management, ARIA ### Discussion * Should we blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. things? Are we okay with keeping that statement: WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) [https://www.w3.org/TR/WCAG21/](https://www.w3.org/TR/WCAG21/). 2.0. * Have things met the standard? Probably not. * What happens in tickets if it’s raised that it doesn’t work for WCAG? * How do we help in that situation? Someone should review major patches. * We don’t want to be a blocker. Accessibility has purification levels. Shoot high, but compromise. * What happens when someone blocks a ticket. It depends, no one really has. * Where’s the acceptable bar? Should work with keyboard only (arrow keys, etc. too). Semantic elements too. Labeled. This is a baseline expectation. * Struggled to know when/where discussions take place sometimes. ## How to involve more developers with accessibility tickets * This is about how to bring more people into this team? * Why do some people stick around and others not stick around? Interesting, important. Time is valuable. * How do we maximize people’s time? Maybe story points, like in Scrum. * People don’t know how best to contribute. * Something like “good first bug” but for accessibility. * Short interview/onboarding for people interested. * Better way to manage priorities. Maybe spreadsheet to try it? * Non-CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. items: Testing, theme reviews, tickets, documentation, support, education * Maybe use more keywords for this? Make list public so people know. * Best way to address is when teams ask for help. * Accessibility slows progress down when it comes at the end. * We need a mental shift of where accessibility fits. We need to let them know they can do it. * Works properly vs. get working. * Get people from outside community. Make a list and ask. Things they can do and achieve. Make a list of people we could bring in. * MITs: Settings APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., 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/](https://wordpress.org/gutenberg/), Media Views, Unified Search – Who? ## How to proceed with the handbook * Make two pages: Tools and resources. Also, how to get involved. * Would potentially be easier to maintain. * Has been hard to get done because everyone is busy. Good examples of ARIA, etc. * How to test resources. * List of what we’re working on. What topics? * ARIA * Keyboard accessibility * Color contrast * Semantics How should we divide topics? * By topic or need? Probably both. * Try to find resources that go beyond accessibility as it relates to disabilities. Who can work on this? * Make small workgroup * Do Google Spreadsheet ## Summary on make/accessibility [Takeaways from Paris](https://make.wordpress.org/accessibility/2017/06/27/takeaways-from-paris/) [#accessibility](https://make.wordpress.org/summit/tag/accessibility/), [#summit-2017](https://make.wordpress.org/summit/tag/summit-2017/) * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsummit%2F2017%2F07%2F31%2Faccessibility-team-community-summit-notes%2F%23respond&locale=en_US) [ ](https://profiles.wordpress.org/georgestephanis/) [George Stephanis](https://profiles.wordpress.org/georgestephanis/) 7:49 pm _on_ December 3, 2012 Tags: a11y, accessibility, eu, standards    # 󠀁[Accessibility](https://make.wordpress.org/summit/2012/12/03/accessibility/)󠁿 ## In Attendance: * Aaron Jorbin * Emil Uzelac * Kevinjohn * Amy Hendrix * Michael Fields * Dave Martin * Jake Goldman * Isaac Keyet * George Stephanis (note taker) ## Discussion Notes Kevinjohn brought up the initial concern that, in the EU, some groups can’t use WordPress, as it hasn’t met some 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) requirements for a few releases now — but we’re close.   Have to meet [AAA](http://ec.europa.eu/ipg/standards/accessibility/validation/index_en.htm) standards for EU. How’s the back-end for accessibility? Jorbin brought up that he, Nacin, and Koop sat down with a blind user and did accessibility testing of post screen — everything was properly set up except for the post box itself. (aside: question of if we should / how we could make it easier for front-end users to be accessible is nipped in the bud for later discussion) Amy Hendrix brought up the question of new accessibility tests for themes — [ which is a work in Progress](https://make.wordpress.org/accessibility/2012/11/12/weve-now-completed-the-draft-theme-accessibility-audit/) What is the accessibility group? [https://make.wordpress.org/accessibility/](https://make.wordpress.org/accessibility/) Aaron Jorbin pointed out that we should get accessibility experts more involved in WordPress. By bringing the accessibility community into the WordPress community, we all benefit. One of the challenges is that it is hard for much of the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team to test accessibility patches do to them not having copies of accessible technology software. A good deal of the software is commercial (or only runs on one operating system) and few people have copies to test patches against. (aside: someone pointed out that it would be nice to automate patch applying by generating trunk installs on the fly and applying patches to them, to enable less- technically-minded people to contribute to testing.  Perhaps on [wpusertesting.com](http://wpusertesting.com) or similar?) We need to migrate from being reactionary to proactive!  While there are a couple patches for 3.5, we may need a set of guidelines for 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) standards, the same way that we have php and css guidelines. It would be very useful to add a high-contrast theme for the admin UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think‘ how are they doing that’ and less about what they are doing.. We also need to emphasize the reasons to focus on accessibility — better SEO results and marketing, for one. The W3CW3C The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.[https://www.w3.org/](https://www.w3.org/). has an article on [the web accessibility business case](http://www.w3.org/WAI/bcase/Overview). (aside: could we possibly include an APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. for toggling high contrast mode on or off?) It would be nice if TwentyThirteen was designed accessible as a number one priority, but how do we get there? We need someone to take responsibility. Isaac Keyet mentions that mobile apps are mostly compliant, but it’s more dependent on the platform that you’re on. Drupal contacted the governments and asked what they needed to do to become fully compliant. We need to get data / feedback that lists what we have already, and what we need to be properly up to spec. Standards — which ones should we focus on? There are multiple options. Checklists to compare patches against would be really helpful! Accessibility is much more than that, but it’s a tool that could help devs not as familiar with Accessibility. Not a solution. Should we add a `not-accessible` or `needs-accessibility` tag in tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.[https://core.trac.wordpress.org/](https://core.trac.wordpress.org/).? These could make it easier and puts accessibility on the same level as UI or UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it.. It’s not a feature, it’s a core asset. We need more accessibility talks at WordCamps … bring accessibility into the popular mindset. ## TAKE AWAYS: * Add a section to the Handbook. * Add in some requirements for patches that they be tested against accessibility guidelines. * Need someone to take ownership for things going forward. * Page on .org talking about what certifications we meet. * Challenge TwentyThirteen to be designed with accessibility as it’s number one Priority. ## Action Item: We want to add WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. [https://wordpress.org/](https://wordpress.org/)/ accessibility which will be a one stop shop for successes we’re having and ways people can get involved. This is partially inspired by [The Drupal Accessibility Page](http://drupal.org/about/accessibility). [#a11y](https://make.wordpress.org/summit/tag/a11y/), [#accessibility](https://make.wordpress.org/summit/tag/accessibility/), [#eu](https://make.wordpress.org/summit/tag/eu/), [#standards](https://make.wordpress.org/summit/tag/standards/)