WCAG success criteria analysis

	A	B	C	D
1	https://www.w3.org/WAI/WCAG22/quickref/		These criteria have been evaluated by someone not an expert in accessibility or WCAG. It's possible that some things I think are fails are actually ok and vice versa.	FAIL
2	Web Content Accessibility Guidelines (WCAG) 2 requirements (success criteria) and techniques.			MEETS CRITERIA
3				more analysis
4
5	WCAG Criteria	WCAG techniques	FTC Docs Notes	Criteria Level
6			number of "A" criteria:	30
7	Principle 1 – Perceivable
8	Information and user interface components must be presentable to users in ways they can perceive.
9	Guideline 1.1 – Text Alternatives. 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.
10	1.1.1Non-text Content	Images, controls, captchas, and things that should be ignored by assistive technology	Our figures use Alt tags but many need adjusting, and complex images need text descriptions. Other items like captchas need evaluation. The Theme switcher and Read the Docs overlay probably need to provide non-visual text alternatives.	A
11
12	Guideline 1.2 – Time-based Media - Provide alternatives for time-based media.
13	1.2.1 Audio-only and Video-only (Prerecorded)	Provide text equivalents	I don't think ftcdocs has any "only" type media	A
14	1.2.2 Captions (Prerecorded)	provide captions to videos	The FTC docs about page YouTube video has closed captioning.	A
15	1.2.3 Audio Description or Media Alternative (Prerecorded)	provide audio and or text description of the video for blind user	I don't think we or YouTube does this. This is like Described Video on a TV channel, someone narrates the non-verbal action.	A
16
17	Guideline 1.3 – Adaptable - Create content that can be presented in different ways (for example simpler layout) without losing information or structure.		I did a simple test of disabling the CSS and at least one page seemed to display ok. We also have desktop and mobile presentation.
18	1.3.1 Info and Relationship	Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.	This needs more investigation, not sure what this means. I think we'll need to review and adjust ARIA labels if needed. Probably need to add text labels to some things like the theme switcher.	A
19	1.3.2 Meaningful Sequence	When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.	Probably ok.	A
20	1.3.3 - Sensory Characteristics	Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.	We have some icons (like the theme switcher) that needs text description	A
21
22	Guideline 1.4 – Distinguishable - Make it easier for users to see and hear content including separating foreground from background.
23	1.4.1 Use of Color	Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.	ftc links need to be underlined, and provide a link hover feature	A
24	1.4.2 Audio Control	If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.	I don't believe ftc-docs has any audio/video that auto-plays	A
25
26
27	Principle 2 – Operable
28	User interface components and navigation must be operable.
29	Guideline 2.1 – Keyboard Accessible - Make all functionality available from a keyboard.
30	2.1.1 Keyboard	All functionality of the content is operable through a keyboard interface ...	The Read the Docs overlay doesn't receive keyboard focus. Need to verify the "are you a human" pop up is keyboard operable.	A
31	2.1.2 No Keyboard Trap	If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface	I haven't noticed any keyboard traps yet.	A
32	2.1.4 Character Key Shortcuts	If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true: ...	We have N=next and P=prev accesskey shortcuts that can't be modified and are active when the next previous buttons DO NOT have focus.	A
33	2.2.1 Timing Adjustable	For each time limit that is set by the content, at least one of the following is true: ...	I don't think ftcdocs has anything, to be confirmed.	A
34	2.2.2 Pause, Stop, Hide	For moving, blinking, scrolling, or auto-updating information, all of the following are true: ...	I don't think ftcdocs has anything, to be confirmed.	A
35	Guideline 2.3 – Seizures and Physical Reactions - Do not design content in a way that is known to cause seizures or physical reactions.
36	2.3.1 Three Flashes or Below Threshold	Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.	I haven't seen anything that blinks/flashes	A
37	Guideline 2.4 – Navigable - Provide ways to help users navigate, find content, and determine where they are.
38	2.4.1 Bypass Blocks	A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.	? we do not have a skip-to-main-content link, but the ARIA labels in the templates may be sufficient.	A
39	2.4.2 Page Titled	Web pages have titles that describe topic or purpose.	ftcdocs titles have extra verbiage that's not required.	A
40	2.4.3 Focus Order	If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.	ftcdocs should be ok here, our content and presentation are essentially sequential.	A
41	2.4.4 Link Purpose (In Context)	The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.	Probably a fail, we link to some PDF's without warning the user. We might need to warn/indicate links external to ftcdocs. Goal-Users understand what each link will do. I have been surpised a few times when links I thought would be an ftcdocs page actually took me to a PDF or to FIRST Inspires.	A
42	Guideline 2.5 – Input Modalities - Make it easier for users to operate functionality through various inputs beyond keyboard.
43	2.5.1 Pointer Gestures	All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.	Goal - Let users operate touchscreens with one finger and reduced gestures. I don't think this is a problem for ftcdocs	A
44	2.5.2 Pointer Cancellation	For functionality that can be operated using a single pointer, at least one of the following is true:	Standard HTML elements are probably ok, need to check the Persona pages where they use fake buttons.	A
45	2.5.3 Label in Name	For user interface components with labels that include text or images of text, the name contains the text that is presented visually.	Goal - The visual label for controls is a trigger for speech activation.	A
46	2.5.4 Motion Actuation	Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:	We should be fine unless the Sphinx Javascript introduces something to the mobile behaviour.	A
47	Principle 3 – Understandable
48	Information and the operation of the user interface must be understandable.
49	Guideline 3.1 – Readable - Make text content readable and understandable.
50	3.1.1 Language of Page	The default human language of each Web page can be programmatically determined.	Ftcdocs uses lang="en"	A
51	Guideline 3.2 – Predictable - Make Web pages appear and operate in predictable ways.
52	3.2.1 On Focus	When any user interface component receives focus, it does not initiate a change of context.	Might be ok, need to test of ToC menu see if mouse vs keyboard causes different types of focus or context changes. Also need to check the blog page that imbeds the blog in an iframe.	A
53	3.2.2 On Input	Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.	I think links opening a new thing might fall under this criteria. There's no warning what clicking the theme switcher will do, or the Read the Docs overlay. also the captcha pops up unexpectedly with a complete change of focus. That's happened using the search input.	A
54	3.2.6 Consistent Help	If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:	I think the ftcdocs submit feedback should be in the footer. In the ToC it jumps around as the ToC repositions.	A
55	Guideline 3.3 – Input Assistance - Help users avoid and correct mistakes.
56	3.3.1 Error Identification	If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.	The feedback form does indicate in text errors when fields have been left empty and are required.	A
57	3.3.2 Labels or Instructions	Labels or instructions are provided when content requires user input.	The feedback form appears to have labels and instructions. The Search box does have 'Search docs' as a hint.	A
58	3.3.7 Redundant Entry	Information previously entered by or provided to the user that is required to be entered again in the same process is either:	I don't think ftcdocs has any process like that.	A
59	Principle 4 – Robust
60	Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.
61	Guideline 4.1 – Compatible - Maximize compatibility with current and future user agents, including assistive technologies.
62	4.1.2 Name, Role, Value	For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined ... Note 1: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.	I believe the theme swticher and the Read the Docs overlay don't have proper accesibility controls. We also need to verify the fake buttons in the persona pages are properly labeled. I think the search input also needs work: <input placeholder="Search docs" type="search" autocomplete="off">	A
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100