Title: Accessibility code standards for WordPress core Author: Rian Rietveld Published: December 15, 2015 --- [ ](https://profiles.wordpress.org/rianrietveld/) [Rian Rietveld](https://profiles.wordpress.org/rianrietveld/) 10:13 am _on_ December 15, 2015   # Accessibility code standards for WordPress core During the WCUS community summit 2015 in Philadelphia we made a start with 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) code standards for WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Joe Dolson put a concept 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) code standards together (see below or as [Google Doc](https://docs.google.com/document/d/1iySvDJ4duHYt6YlnnjnBNbU5LKAn1uRBMH8FKAfmswE/edit#)). These are the standards expected from new code (like feature plugins) at the time it’s to be merged into core. Our target for released code is WCAG2.0 AA. Proposed place to put them is the Core Handbook: [WordPress Coding Standards](https://make.wordpress.org/core/handbook/best-practices/coding-standards/), we aim for a short list of very basic things with references to the Accessibility Handbook. Feedback (in the comment section below) is very welcome. ### Concept Accessibility code standards for core: This document is a list of standards that a WordPress feature plug-in should meet for accessibility in order to be merged into core. These standards are focused on best practices and easily testable concerns. The expectations for all code released in WordPress is conformance with 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 at the AA level. * 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. Semantics * Headings Hierarchy * Definition of HTML for Controls * Usage of ARIA * Color Contrast * Keyboard Accessibility * Images and Icons * Labeling #### HTML Semantics Take a pragmatic approach to HTML semantics. Don’t add semantics purely for the sake of semantics; but if there is an HTML structure that clearly matches the content, use that element. For example, if you have a group of links, it should most likely use a list element. #### Heading structure The H1 is the main heading representing the page title on every core page. For sub sections, use a reasonable HTML heading structure — including the use of heading elements for page sub-sections. Heading markup should not be used for presentational purposes. * Use H2 through H6 to give internal structure to the page. * Don’t skip heading levels. * Don’t add extra functionality inside a heading, like links or buttons. #### Semantics for Controls Controls with a native keyboard interaction (buttons or links) are always preferred. If there is a valid target link for the control, either an in-page reference or a link, then the control should use an . If there isn’t, it should use a