You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Code integrated into the WordPress ecosystem - including WordPress core, WordPress.org websites, and official plugins, is expected to conform to the Web Content Accessibility Guidelines (WCAG), version 2.1, at level AA.
3
+
Code integrated into the WordPress ecosystem - including WordPress core, WordPress.org websites, and official plugins, is expected to conform to the Web Content Accessibility Guidelines (WCAG), version 2.1, at level AA.
4
4
5
-
New or updated interfaces are encouraged to incorporate the Authoring Tool Accessibility Guidelines (ATAG) 2.0. The most significant way that ATAG 2.0 guidelines can be incorporated is by emphasizing choices that help people make more accessible content: encouraging alternative text, captions, and semantic structures, for example.
5
+
New or updated interfaces are encouraged to incorporate the Authoring Tool Accessibility Guidelines (ATAG) 2.0. The most significant way that ATAG 2.0 guidelines can be incorporated is by emphasizing choices that help people make more accessible content: encouraging alternative text, captions, and semantic structures, for example.
6
6
7
7
Official information about web accessibility standards can be divided into two groups: "normative" and "informative" documents. Only the guidelines themselves are normative, and establish the actual requirements for conforming to WCAG 2.1. Other documents should be considered to be informational, and offer help in interpreting the guidelines, but are not definitive.
8
8
9
9
The WordPress A11y team is in the process of developing a library of recommended accessibility patterns to help describe the WordPress recommended way to accomplish a variety of interfaces. These may not be the only reasonable way to create an accessible example of the pattern, but are preferred for the sake of consistency across WordPress.
-[W3C Introduction to ATAG](https://www.w3.org/WAI/standards-guidelines/atag)
21
23
22
-
## About WCAG A, AA, and AAA Conformance Levels
24
+
## About WCAG A, AA, and AAA Conformance Levels
25
+
23
26
The WordPress commitment is to conform to all WCAG 2.1 Level A and Level AA guidelines. Conformance to level AAA success criteria is encouraged where relevant, as is exceeding the accessibility of any of these guidelines.
24
27
25
28
**Level A** success criteria address concerns considered to be accessibility barriers on a very wide scale that will prevent many people from accessing the site and the minimum set of accomplished goals required for the majority of web-based interfaces.
26
29
27
30
**Level AA** success criteria address concerns that are generally somewhat more complicated to address and may impact smaller groups of people, but are still common needs with broad reach.
28
31
29
-
**Level AAA** success criteria are mostly targeted at very specific needs and may be quite difficult to implement effectively.
32
+
**Level AAA** success criteria are mostly targeted at very specific needs and may be quite difficult to implement effectively.
30
33
31
34
[W3C Quick Reference to WCAG 2.1 Level A and Level AA Requirements](https://www.w3.org/WAI/WCAG21/quickref/?versions=2.1¤tsidebar=%23col_overview&levels=aaa)
32
35
33
-
## Applying WCAG Conformance Levels
36
+
## Applying WCAG Conformance Levels
37
+
34
38
WCAG 2.1 consists of 4 layers:
39
+
35
40
- Principles
36
41
- Guidance
37
42
- Success criteria
38
43
- Sufficient and advisory techniques
39
44
40
45
### Principles
46
+
41
47
When applying WCAG 2.1, the guidance and success criteria are organized around 4 principles. These principles place emphasis on how people interact with content and must be:
42
-
-**Perceivable** - interacting with the content using the medium that they are familiar with. For example, providing text alternatives for those who are blind.
43
-
-**Operable** - finding and using content is accessible. For example, being able to use a keyboard or a screen reader.
48
+
49
+
-**Perceivable** - interacting with the content using the medium that they are familiar with. For example, providing text alternatives for those who are blind.
50
+
-**Operable** - finding and using content is accessible. For example, being able to use a keyboard or a screen reader.
44
51
-**Understandable** - content uses clear language and is understandable. For example, use meaningful labels, explain all abbreviations.
45
52
-**Robust** - content can be interpreted in a range of ways. For example, assistive technologies are able to interpret and parse content.
46
53
47
54
### Guidance
55
+
48
56
Each principle is supported by a list of guidelines to ensure that content is more accessible and presentable across the different devices that meet a user’s disability. The guidelines are listed below, the full detail can be found in the WCAG 2.1.
49
57
50
58
#### Principle: Perceivable
59
+
51
60
**Guideline 1.1 Text Alternatives**
52
61
Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
53
62
@@ -61,6 +70,7 @@ Create content that can be presented in different ways (for example simpler layo
61
70
Make it easier for users to see and hear content including separating foreground from background.
62
71
63
72
#### Principle: Operable
73
+
64
74
**Guideline 2.1 Keyboard Accessible**
65
75
Make all functionality available from a keyboard.
66
76
@@ -77,6 +87,7 @@ Provide ways to help users navigate, find content, and determine where they are.
77
87
Make it easier for users to operate functionality through various inputs beyond keyboard.
78
88
79
89
#### Principle: Understandable
90
+
80
91
**Guideline 3.1 Readable**
81
92
Make text content readable and understandable.
82
93
@@ -87,43 +98,50 @@ Make Web pages appear and operate in predictable ways.
87
98
Help users avoid and correct mistakes.
88
99
89
100
#### Principle: Robust
101
+
90
102
**Guideline 4.1 Compatible**
91
103
Maximize compatibility with current and future user agents, including assistive technologies.
92
104
93
105
### Success Criteria
106
+
94
107
Each guidance has a [specific list requirements that must be met for your content to be accessible](https://www.w3.org/WAI/WCAG21/quickref/). These tests can be carried out using automated software and or human testers. You can find more information on how to meet the success criteria in [Understanding Levels of Conformance](https://www.w3.org/WAI/WCAG21/Understanding/conformance#levels). Whilst these criteria are important, usability testing is still important and should be carried out alongside any accessibility testing.
95
108
96
109
### Techniques: Sufficient, Advisory, and Failures
110
+
97
111
Techniques (code examples, resources, and tests) for guidance and success criteria that can help in making content more accessible, are divided into three categories:
112
+
98
113
- Sufficient - required and help meet the success criteria
99
114
- Advisory - suggestions and go beyond what is required
100
115
- Failures - cause problems and fail to meet the success criteria
116
+
101
117
For more information on techniques, visit [Understanding Techniques for WCAG Success Criteria](https://www.w3.org/WAI/WCAG21/Understanding/understanding-techniques).
102
118
103
119
## Authoritative Resources
120
+
104
121
-[WebAIM: Web Accessibility In Mind](https://webaim.org/) (see Articles and Resources)
105
122
-[Government Digital Service](https://gds.blog.gov.uk)
106
-
-[Accessibility in government](https://accessibility.blog.gov.uk/)
123
+
-[Accessibility in government](https://accessibility.blog.gov.uk/)
107
124
-[Blog | TPG – The Accessibility Experts](https://developer.paciellogroup.com/blog/)
108
125
-[Web Accessibility Blog (Deque)](https://www.deque.com/blog/)
-[Accessibility London (London, United Kingdom)](https://www.meetup.com/London-Accessibility-Meetup/) (London accessibility meetup: they live stream meetups on youtube)
118
135
-[24 Accessibility](https://www.24a11y.com/)
119
136
-[Mozilla Accessibility - Users first, no matter their abilities](https://blog.mozilla.org/accessibility/)
120
137
121
-
### Technical and / or specific topics:
138
+
### Technical and / or specific topics
139
+
122
140
-[Accessibility Support](https://a11ysupport.io/) (Will your code work with assistive technologies?)
123
-
-[Accessibility APIs: A Key To Web Accessibility](https://www.smashingmagazine.com/2015/03/web-accessibility-with-accessibility-api/) (by Léonie Watson)
124
-
-[How accessibility trees inform assistive tech](https://hacks.mozilla.org/2019/06/how-accessibility-trees-inform-assistive-tech/) (by Hidde de Vries)
141
+
-[Accessibility APIs: A Key To Web Accessibility](https://www.smashingmagazine.com/2015/03/web-accessibility-with-accessibility-api/) (by Léonie Watson)
142
+
-[How accessibility trees inform assistive tech](https://hacks.mozilla.org/2019/06/how-accessibility-trees-inform-assistive-tech/) (by Hidde de Vries)
125
143
-[What is this thing and what does it do?](https://www.youtube.com/watch?v=YLihNhn_MO4) (presentation by Karl Groves)
126
144
-[The Browser Accessibility Tree](https://developer.paciellogroup.com/blog/2015/01/the-browser-accessibility-tree/) (by Steve Faulkner)
127
-
-[Brief history of browser accessibility support](https://www.paciellogroup.com/blog/2011/10/brief-history-of-browser-accessibility-support/) (by Steve Faulkner)
145
+
-[Brief history of browser accessibility support](https://www.paciellogroup.com/blog/2011/10/brief-history-of-browser-accessibility-support/) (by Steve Faulkner)
128
146
-[ARIA Landmarks Example: General Principles](https://www.w3.org/TR/wai-aria-practices/examples/landmarks/)
129
-
-[ARIA Landmarks Example: HTML Sectioning Elements](https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html)
147
+
-[ARIA Landmarks Example: HTML Sectioning Elements](https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html)
0 commit comments