Test Procedures & Requirements

The Visa Global Accessibility Requirements (VGAR) is a combination of requirements and complimentary test procedures that help teams implement and verify accessible web experiences.

For accessibility testing, the tester simply executes the test cases and determines whether each page being tested passes or fails the test case. When a failure is found, the tester then documents the failure and provides it to the development team for remediation.  The development team subsequently references both the identified failure and the corresponding requirement to assist in the remediation effort.

Test Order    |    Requirement Order

Requirement Order

The following table contains the VGAR web requirements, they are ordered for the ideal reading over for developers.

Order Requirement ID Related Spec WCAG Parallel Level Short Name Requirement
1 PAG-WEB-001-01 WCAG 2.0 4.1.1 Parsing A Valid Code All HTML pages MUST have code that is fully valid. 
2 PAG-WEB-002-01 WCAG 2.0 4.1.1 Parsing A Doctype A valid doctype MUST be set for all pages.
3 PAG-WEB-003-01 WCAG 2.0 2.4.2 Page Titled A Page Title An accurate and descriptive page <title> MUST be included on every page.
4 PAG-WEB-003-02 WCAG 2.0 2.4.2 Page Titled A Unique Page Title The page title MUST be unique and conform to a consistent structure among the other pages.
5 PAG-WEB-004-01 WCAG 2.0 3.1.1 Language of Page A Lang Attribute The applicable <lang> MUST be defined on every page, inside the html tag.
6 PAG-WEB-005-01 WCAG 2.0 1.3.1 Info and Relationships A Iframe Use Iframes SHOULD only be used if absolutely necessary due to potential confusion for screen reader users.
7 PAG-WEB-005-02 WCAG 2.0 4.1.2 Name, Role, Value AA Iframe Titles Iframes intended for user interaction MUST have a unique, descriptive, and consistent <title> so users can identify it easily.
8 PAG-WEB-005-03 WCAG 2.0 1.3.1 Info and Relationships A System iframes “System” iframes, such as iframes used for analytics MUST be hidden from all users by using the following: 
• Set CSS style to display:none
• Set aria-hidden attribute to true for the iframe (i.e. aria-hidden="true")
9 INT-WEB-010-01 WCAG 2.0 4.1.2 Name, Role, Value AA Name Custom Controls When a custom control is used in place of a native control, the control's name MUST be made available to assistive technology using a method such as aria-label or aria-labelledby.
10 INT-WEB-010-02 WCAG 2.0 4.1.2 Name, Role, Value AA Emulate Custom Controls When using a custom control in place of a corresponding native control, the custom control MUST fully describe everything a native control would to assistive technology (e.g. name, role, state, value, and properties).
For example:
• ARIA Input: role=”textbox”
• ARIA Textarea: role=”textbox” and aria-multiline=”true”
• ARIA Radio: role=”radio” and aria-checked=”true”
• ARIA Checkbox: role=”checkbox” and aria-checked=”true”
• ARIA Dropdown: role=”listbox” with role=”option” and aria-selected=”true” and aria-owns="ID1 ID2" where the IDs are in a space delimited list of the IDs of all of the options if those options are not children of the control in the DOM.
11 INT-WEB-010-03 WCAG 2.0 2.1.1 Keyboard A Custom Control Interaction When using a custom control or element in place of a corresponding native control (e.g., select) or element (e.g., table), the user MUST be able to interact using the same keyboard commands they would with the native equivalent unless text instructions are made available to ALL users (i.e. visually and to assistive technologies) preceding the control or element.
12 INT-WEB-010-04 WCAG 2.0 4.1.2 Name, Role, Value AA Expand Collapse State When using an expanding and collapsing UI element such as an accordion style menu, the current state of each expanding/collapsing element MUST be announced to assistive technology (e.g. Screen Readers). 
13 PAG-WEB-008-01 WCAG 2.0 1.3.1 Info and Relationships A Hide from Sighted Users To hide content from sighted users (but not screen readers) the content MUST be moved off screen using CSS.

 for example:
 .hide-visually-but-not-from-screen readers {
  position: absolute;
  top: -9999px !important;
  left: -9999px !important;
  }
14 PAG-WEB-008-02 WCAG 2.0 1.3.1 Info and Relationships A Hide from Screen Readers To hide content from screen readers (but not sighted users) the following attributes MUST be used:
• aria-hidden="true"
• Set the tabindex="-1"
15 PAG-WEB-008-03 WCAG 2.0 1.3.1 Info and Relationships A Hide from All Users To hide content from everyone, the content SHOULD be removed from the DOM, or if not possible, it MUST be hidden using the following techniques:

for example (CSS):
.hide-from-everyone{
  display:none;
  visibility:hidden;
  }

for example (HTML):
<div class="hide-from-everyone" aria-hidden="true">Hidden Info</div>
16 PAG-WEB-009-01 WCAG 2.0 4.1 Compatible N/A Support Screen readers All features and functionality made available to users within the web application MUST be functionally supported with at least one screen reader per supported platform (i.e. JAWS for Windows desktop, VoiceOver for iOS, etc.). 
17 PAG-WEB-009-02 WCAG 2.0 4.1 Compatible N/A Alerts Read When alerts are shown on screen (i.e., success, error, or status/informative) they MUST also be read aloud by each supported screen reader. 
18 PAG-WEB-009-03 WCAG 2.0 4.1 Compatible N/A Screen Updates Read When the user takes an action resulting in a visual change to the screen above the focus (e.g., user entered a Visa card number and the Visa logo above the input highlights onblur), each supported screen reader MUST inform the user of this change.
19 PAG-WEB-009-04 WCAG 2.0 4.1 Compatible N/A Page Title Reads The page title MUST be properly read aloud by each supported screen reader on page load or when the URI changes on Single Page Architecture web applications. 
20 PAG-WEB-009-05 WCAG 2.0 4.1 Compatible N/A Iframes List Reads When the list of iframes is requested by the user (or the user attempts to cycle through each), each supported screen reader MUST accurately identify all Frames designed for user interaction by reading their titles. 
21 PAG-WEB-009-06 WCAG 2.0 4.1 Compatible N/A No System iframes Read When the list of iframes is requested by the user (or the user attempts to cycle through each), each supported screen reader MUST NOT list any iframes designed for “system use”
22 OAG-WEB-009-07 WCAG 2.0 4.1 Compatible N/A Landmarks List Reads When the list of Landmarks is requested by the user (or the user attempts to cycle through each), each supported screen reader MUST accurately identify all Landmark regions by role.
23 PAG-WEB-009-08 WCAG 2.0 4.1 Compatible N/A Multi Landmark Labels Read When the list of Landmarks is requested by the user (or the user attempts to cycle through each), and there are multiple navigation landmarks on the screen, each supported screen reader MUST accurately identify each uniquely by reading both the role and label.
24 PAG-WEB-009-09 WCAG 2.0 4.1 Compatible N/A Headings List Reads When the list of headings is requested by the user (or the user attempts to cycle through each), the headings MUST be read accurately by each supported screen reader.
25 PAG-WEB-009-10 WCAG 2.0 4.1 Compatible N/A Links List Reads When the list of links is requested by the user, link text MUST be present and read accurately for each link by each supported screen reader.
26 PAG-WEB-010-01 WCAG 2.0 4.1 Compatible N/A A11y Validator Tool When run against the page, the HTML_CodeSniffer accessibility validation tool MUST NOT report any errors.
27 NAV-WEB-001-01 WCAG 2.0 2.1.1 Keyboard A Keyboard Only All functionality and content MUST be available to users via the keyboard only (without a mouse) without requiring specific timing of keystrokes.
28 NAV-WEB-001-02 WCAG 2.0 2.1.1 Keyboard A Keyboard Events Onmouseover / onmouseout events MUST be accompanied by onfocus / onblur
29 NAV-WEB-001-03 WCAG 2.0 2.1.1 Keyboard A No 3rd Party Tools 3rd party tools, plugins, and applets SHOULD not be used in the web application as it makes accessibility compliance more complicated, and this SHOULD be considered before choosing 3rd party technologies.
30 NAV-WEB-001-04 WCAG 2.0 2.1.2 No Keyboard Trap A No Keyboard Trap If any part of the UI takes control of keyboard focus (e.g., PDF viewer or modal window) it MUST, through keyboard commands only, allow focus to return to the launching element and browser. 
31 NAV-WEB-001-05 WCAG 2.0 2.1.1 Keyboard A Use OnBlur not OnChange Onblur MUST be used instead of onchange, unless absolutely necessary and it causes no negative consequences for keyboard only or screen reader users.  
32 NAV-WEB-001-06 WCAG 2.0 2.1.1 Keyboard A No Context Change onFocus Changes of context MUST not be initiated onfocus.
33 NAV-WEB-001-07 WCAG 2.0 2.1.1 Keyboard A Warn for Context Change Changes to the screen caused by onblur or onchange events SHOULD be minor enough that they are not a change of context.  If changes are major enough to be a change of context, they MUST be user initiated (e.g., with a “go” button) or the user MUST be informed of the change ahead of time with text onscreen (not visually hidden).
34 NAV-WEB-002-01 WCAG 2.0 2.4.7 Focus Visible AA Visible Keyboard Focus A highly visible cue MUST always be presented to indicate keyboard focus.
35 NAV-WEB-002-02 WCAG 2.0 1.4.1 Use of Color, 2.4.3 Focus Order A, A Disabled Control Focus When a form field or control is disabled it SHOULD not receive keyboard focus.  Doing this reinforces 1.4.1 Use of Color so that the only means of conveying that a control is disabled doesn't rely solely on color (https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html)
36 NAV-WEB-002-03 WCAG 2.0 2.4.3 Focus Order A Default Tab Order Default tab order of focusable elements MUST not be overridden; the natural order of the HTML code SHOULD match the rendered page’s logical order.
37 NAV-WEB-003-01 WCAG 2.0 1.3.1 Info and Relationships      2.4.1 Bypass Blocks A, A Base ARIA Landmark Regions Each page MUST have (at a minimum) one of each of the following ARIA landmark regions: 1) Banner, 2) Navigation, 3) Main, and 4) Contentinfo.
38 NAV-WEB-003-02 WCAG 2.0 1.3.1 Info and Relationships      2.4.1 Bypass Blocks A, A Extra ARIA Landmark Regions Pages MUST also use the following ARIA landmark regions when needed: Complementary, Search
39 NAV-WEB-003-03 WCAG 2.0 1.3.1 Info and Relationships      2.4.1 Bypass Blocks A, A Keep All Content in Regions All rendered content MUST be within one or more (through nesting regions) of the following landmark regions, as appropriate: Main, Navigation, Banner, Contentinfo, Complementary, Search
40 NAV-WEB-003-04 WCAG 2.0 1.3.1 Info and Relationships      2.4.1 Bypass Blocks A, A Label Multiple Landmarks If a page has multiple landmarks of the same type (e.g., Main Nav and Sub Nav), those regions MUST be labeled to facilitate differentiation using aria-label.
41 NAV-WEB-003-05 WCAG 2.0 2.4.1 Bypass Blocks A Skip to Login Link If a page has a “login” feature and focus is not automatically set to the login field on page load, the page MUST include a “skip to login” link as the first link on the page.  The link MUST move focus to the login field and may be visually hidden until it has focus.
42 NAV-WEB-003-06 WCAG 2.0 2.4.1 Bypass Blocks A Skip to Content Link A “skip to content” link MUST be included on every page as the first link (or second if “skip to login” link is present) on the page.  The link MUST skip to the main content of the page or the errors summary if present and may be visually hidden until it has focus.
43 NAV-WEB-003-07 WCAG 2.0 1.3.1 Info and Relationships      2.4.1 Bypass Blocks A, A Headings have Priority over Sections If HTML5 sections are used within the “Main” ARIA Landmark role, they MUST NOT interfere with a properly nested heading structure.
44 NAV-WEB-004-01 WCAG 2.0 2.1.1 Keyboard A No Access Keys Access keys MUST not be used.
45 NAV-WEB-005-01 WCAG 2.0 2.4.5 Multiple Ways AA More than one Way to Find Content Users MUST be provided more than one way to find content within a website except when the web page is the result of a step or process.  This provision MUST include two or more of the following navigational methods:
• Links to navigate to related Web pages
• a Table of Contents
• a Site Map
• a search function
• a list of links to all other Web pages
• Linking to all of the pages on the site from the home page
46 NAV-WEB-006-01 WCAG 2.0 3.2.3 Consistent Navigation  AA Same Relative Order  Components that appear on multiple pages MUST appear in the same relative order on every page.
47 NAV-WEB-006-02 WCAG 2.0 3.2.4 Consistent Identification AA Name Consistently Consistent labels, names, and text alternatives MUST be used for content that has the same functionality.
48 NAV-WEB-006-03 WCAG 2.0 2.4.9 Link Purpose (Link Only) AAA Consistent or Unique Link Text Links with the same HREF MUST have the same link text and vice versa, and links with different HREFs MUST have different link text and vice versa.
49 NAV-WEB-006-05 WCAG 2.0 2.1.1 Keyboard A Keyboard Accessible Scrollable Divs Scrollable divs that do not contain any keyboard focusable content MUST have the following technique implemented for keyboard accessibility:
• The containing div must have a tabindex="0"
50 NAV-WEB-007-01 WCAG 2.0 4.1.2 Name, Role, Value A Pagination is Navigation Pagination controls MUST have the attribute role=”navigation”.
51 NAV-WEB-007-02 WCAG 2.0 4.1.2 Name, Role, Value A Label Pagination Pagination controls MUST have the attribute aria-label=”Pagination”.  If there are more than one pagination controls on a page, they MUST have unique labels, but still contain the word "Pagination".
52 NAV-WEB-008-01 WCAG 2.0 2.4.8 Location AAA Wizard Context Provided Process or Wizard Step Indicators MUST provide context and status to screen readers (e.g., "Current Step: Add Card, Step 2 of 4").
53 NAV-WEB-008-02 WCAG 2.0 2.4.8 Location AAA Wizard Info in Title / H1 Any Process or Wizard Step Indicator information MUST be included in the page title and H1.
54 INT-WEB-001-01 WCAG 2.0 1.3.1 Info and Relationships A Fully Descriptive Control Labels Form controls MUST have one unique label attribute that fully describes the control’s purpose, including any supplementary information that the visual presentation may also provide (e.g., related controls grouped together visually).  The only exception to uniqueness is if fieldsets are used to make non-unique labels unique as described in INT-WEB-001-05.
55 INT-WEB-001-02 WCAG 2.0 3.3.2 Labels or Instructions A Label Controls (or title) Form controls MUST use a label unless it is not possible given the visual layout, at which point aria-labelledby MUST be used unless it is not possible, at which point aria-label MUST be used.
56 INT-WEB-001-03 WCAG 2.0 3.3.2 Labels or Instructions A Hide part of labels Some or all of a label can be hidden with CSS if the visual presentation provides the necessary context.
57 INT-WEB-001-04 WCAG 2.0 1.3.1 Info and Relationships A Use Label for= Form controls using a label to identify them MUST have only one label that is programmatically associated with the control using: label for=”<ID of control>”
58 INT-WEB-001-05 WCAG 2.0 2.4.6 Headings and Labels                      AA Group controls using Fieldsets When there is more than one distinct group of related form controls on a page, the related controls SHOULD be grouped programmatically using fieldsets with legends that describe the logical grouping if possible.  Fieldset legends can be hidden off screen if they aren’t visually necessary.
59 INT-WEB-001-06 WCAG 2.0 2.4.6 Headings and Labels AA Group controls using headings When there is more than one distinct group of related form controls on a page and the related controls are not grouped using fieldsets, they MUST be grouped programmatically using headings. 
60 INT-WEB-001-07 WCAG 2.0 1.3.1 Info and Relationships     
3.3.2 Labels or Instructions
3.3.3 Error Suggestion
A, A, AA Use Aria-required Required controls MUST use the aria-required=”true” attribute.
61 INT-WEB-001-08 WCAG 2.0 1.3.1 Info and Relationships A Use aria-describedby Helper text MUST be programmatically associated with a form control using aria-describedby=”<ID of helper texts container>”
62 INT-WEB-002-01 WCAG 2.0 3.3.1 Error Identification A Check for Errors All pages that accept user input MUST check for errors and allow the user to correct them.
63 INT-WEB-002-02 WCAG 2.0 3.3.4 Error Prevention AA Summary before Submit If user input is collected across multiple pages in order to execute a transaction of some kind, the user MUST be presented with a summary of the input before submitting.
64 INT-WEB-002-03 WCAG 2.0 4.1.2 Name, Role, Value A Use Aria-Invalid Controls that are being validated for errors MUST include aria-invalid="false" inside the <input> field. The aria-invalid attribute MUST be managed programmatically, when an error is being detected aria-invalid MUST be set to true, but when valid data is present then it MUST be set to false.
65 INT-WEB-002-04 WCAG 2.0 3.3.1 Error Identification
3.3.3 Error Suggestion
A, AA Highlight Errors When an error is detected using client side validation, highlight the field (e.g., with a bold red border, error icon with proper alternative text) and place error helper text near it.
66 INT-WEB-002-05 WCAG 2.0 3.3.1 Error Identification
3.3.3 Error Suggestion
A, AA Client Side Alerts When an error is detected using client side validation, any previous role=”alert” instances MUST be removed from the DOM, and role="alert" MUST be set on the container of the error_helpertext.
67 INT-WEB-002-06 WCAG 2.0 3.3.1 Error Identification
3.3.3 Error Suggestion
A, AA Client Side Errors When an error is detected using client side validation the following MUST be programmatically accommodated; 1) set aria-invalid="true", 2) and add the ID of the error helper text container to the aria-describedby attribute if present, 3) or add an aria-describedby attribute if not. 
Example:  aria-describedby=”helpertext” changes to aria-describedby=”error_helpertext helpertext”
68 INT-WEB-002-07 WCAG 2.0 3.3.1 Error Identification
3.3.3 Error Suggestion
A, AA Server Side Errors When an error is detected using server side validation (i.e., multiple errors may be detected at once), 1) a list of the errors MUST be placed in an alert box (messaging element), 2) the alert box MUST be placed directly below the <h1>, 3) any previous role=”alert” instances MUST be removed from the DOM, 4) the alert box/container MUST have role=”alert” set for the messaging elements heading (e.g. “There were <number of> errors”), and 5) the focus MUST be automatically set to the first invalid form control.
69 INT-WEB-003-01 WCAG 2.0 4.1.2 Name, Role, Value A System Messages role=Status System messages and success messages MUST include the ARIA role=”status” and aria-live=”assertive” on the message container when it is added to the DOM.
70 INT-WEB-003-02 WCAG 2.0 4.1.2 Name, Role, Value A System Messages after Submit To ensure that aria-live=”assertive” does not cause  messages to interrupt users, system and success messages SHOULD only be added to the DOM after a button press or on page reload.
71 INT-WEB-004-01 WCAG 2.0 4.1.2 Name, Role, Value A Modal Role=Dialog Modal windows MUST have the role attribute on the modal container set to role=“dialog”
72 INT-WEB-004-02 WCAG 2.0 4.1.2 Name, Role, Value A Modals have titles Modal windows MUST have aria-labelledby=“dialog-title” where dialog-title would be the modal’s title (e.g., main heading in modal).
73 INT-WEB-004-03 WCAG 2.0 1.3.1 Info and Relationships A Modals have descriptions Modal windows SHOULD have aria-describeby=“dialog-desc” where dialog-desc is some helpful information that is above the first focusable element.
74 INT-WEB-004-04 WCAG 2.0 2.4.3 Focus Order A Modals trap focus Modal windows MUST trap focus inside the modal.
75 INT-WEB-004-05 WCAG 2.0 2.4.3 Focus Order A Modals set focus Modal windows MUST have focus set to enable action without confusion. If the modal is primarily presenting text (including links) the focus SHOULD be placed on the heading or beginning of the text content to allow screen reader users to begin there. If the modal's goal is using interactive elements (i.e. form, button, etc.), focus SHOULD be placed on the first interactive element inside the modal, excluding any close button(s).
76 INT-WEB-004-06 WCAG 2.0 2.4.3 Focus Order A Modals wrap around Modal windows MUST allow the user to move through the modal's focusable elements, “wrapping around” from bottom-to-top and top-to-bottom using the <TAB> and <SHIFT>+<TAB> keyboard events.
77 INT-WEB-004-07 WCAG 2.0 2.4.3 Focus Order A Modals prevent clicks outside Modal windows MUST prevent mouse-clicks that occur outside the modal from having any effect on the modal.
78 INT-WEB-004-08 WCAG 2.0 2.1.1 Keyboard A Modals trigger on Enter Modal windows MUST have the <ENTER> keyboard event trigger set as the modal's main call-to-action (e.g. Submit form, etc.).
79 INT-WEB-004-09 WCAG 2.0 2.1.1 Keyboard A Modals close on ESC Modal windows MUST have the <ESC> keyboard event set to close the modal.
80 INT-WEB-004-10 WCAG 2.0 2.4.3 Focus Order A Modals restore focus Modal windows MUST restore focus to their triggering element when modal is closed.
81 INT-WEB-005-01 WCAG 2.0 3.2.1 On Focus A Don't use onchange or onfocus The onchange and onfocus events MUST not be utilized to perform any actions for the user.
82 INT-WEB-005-02 WCAG 2.0 3.2.2 On Input A Use "Go" buttons The onblur event MUST not be used to perform any user action, unless deemed absolutely necessary.  A “go” button is always the preferred approach in this instance.
83 INT-WEB-005-03 WCAG 2.0 3.2.2 On Input A Warn users in text and with describedby When an onblur event MUST be used to cause a “significant” change to a page, the page MUST 1) describe what will happen via a textual description to the user prior the control being triggered, and 2) aria-describedby=”<ID OF CONTAINER OF THAT TEXT>” MUST be included within the control to ensure the screen reader users will receive the message.
84 INT-WEB-006-01 WCAG 2.0 4.1.2 Name, Role, Value A Use native buttons Native buttons (i.e., not links, divs, or spans styled to look like buttons) MUST be used to trigger actions unless this approach is not possible, in which case the element MUST have role=”button” so it appears to the assistive technology as a button.
85 INT-WEB-006-02 WCAG 2.0 2.4.4 Link Purpose (In Context) A Descriptive Link Text Links MUST indicate where they go in a unique and descriptive way to give users an understanding of and confidence in their destination.
86 INT-WEB-006-03 WCAG 2.0 4.1.2 Name, Role, Value A No links to javascipt void or # Links MUST not point to "javascript:void(0);" nor "#"
87 INT-WEB-007-01 WCAG 2.0 2.2.2 Pause, Stop, Hide A Pause, stop, hide moving content A mechanism MUST be provided to pause, stop, or hide any content that meets the following criteria:
• Starts automatically
• Is presented in parallel with other content
AND
• moves, blinks or scrolls for >5 seconds
OR
• All auto-updating content regardless of duration
88 INT-WEB-007-02 WCAG 2.0 1.4.2 Audio Control A Pause or adjust volume for auto playing audio For any audio which 1) plays automatically and 2) lasts for >3 seconds, ONE of the following MUST be true:
• A mechanism to pause the content is presented to the user
OR
• A mechanism for adjusting the volume of the content is presented to the user AND it does not rely on the system audio levels to adjust the volume.
89 INT-WEB-008-01 WCAG 2.0 2.3.1 Three Flashes or Below Threshold A No blinking for flashing Content that blinks or flashes MUST never be used.
90 INT-WEB-009-01 WCAG 2.0 2.2.1 Timing Adjustable A Warn about timeout Users MUST be warned prior to when a session times out and expires.
91 INT-WEB-009-02 WCAG 2.0 2.2.1 Timing Adjustable A Extent timeout Users MUST be given at least 30 seconds to take action in order to avoid a session time out by extending the time limit (of a session) via a “simple” user action (e.g., "press the space bar").
92 CON-WEB-001-01 WCAG 2.0 2.4.6 Headings and Labels AA Use Headings (H1 etc.) Pages MUST organize content using headings (e.g., H1, H2, etc.).
93 CON-WEB-001-02 WCAG 2.0 2.4.6 Headings and Labels AA One H1 per page Each page MUST have only one H1.
94 CON-WEB-001-03 WCAG 2.0 1.3.2 Meaningful Sequence A H1 at top of Main The H1 MUST be within and at the top of the Main ARIA Landmark, with no content above it.
95 CON-WEB-001-04 WCAG 2.0 1.3.2 Meaningful Sequence A Sequential Headings Headings MUST occur in a sequential and increasing order (i.e., Heading 1, then Heading 2, then Heading 3 and so on, no skipping numbers).
96 CON-WEB-001-05 WCAG 2.0 1.3.2 Meaningful Sequence A Properly Nested Headings Headings MUST be nested properly (i.e., 2 is always a child of 1, and 3 is always a child of 2, and so on)
97 CON-WEB-002-01 WCAG 2.0 1.3.1 Info and Relationships A Semantically mark up text Whenever content conveys information through presentation of text, appropriate semantic markup (e.g., em, strong, cite, blockquote, sub, and sup) MUST be used.  
98 CON-WEB-003-01 WCAG 2.0 2.4.3 Focus Order A Code order = logical content order The logical order of content MUST be present in the code order, allowing for successful use of the content when linearized and/or without CSS.
99 CON-WEB-003-02 WCAG 2.0 2.4.3 Focus Order A Remove or Park "hidden" content at the bottom “Hidden” content being "parked" for later (e.g., the text to be used by a JS calendar picker) SHOULD be removed from the DOM if possible, and if not it  SHOULD be placed at the bottom.
100 CON-WEB-004-01 WCAG 2.0 1.3.1 Info and Relationships A Mark up lists and paragraphs Paragraphs MUST be marked up as such.
101 CON-WEB-004-02 WCAG 2.0 1.3.1 Info and Relationships A Group items with lists Groups of items (e.g., a navigation menu or group of tabs) MUST be marked up as a list.
102 CON-WEB-005-01 WCAG 2.0 2.4.4 Link Purpose A Link text in and out of context Link text MUST describe the destination or purpose of every link in a way that makes the destination or purpose clear to all users when taken out of context (i.e., in a list of links for the page).  Some of the link text may be hidden via CSS provided the text left visible makes sense when taken in context of the enclosing sentence, table header(s) or preceding heading.
103 CON-WEB-006-01 WCAG 2.0 1.3.3 Sensory Characteristics A Instructions don’t rely on visual cues Instructions MUST never refer solely to visual cues such as size, shape, color, or spatial directions.
104 CON-WEB-006-02 WCAG 2.0 1.3.3 Sensory Characteristics A Instructions include labels as cues Text labels and/or names MUST be used when providing instructions to allow users who cannot perceive other indicators to locate elements.
105 CON-WEB-007-01 WCAG 2.0 3.1.2 Language of Parts AA Lang of parts of page A lang attribute MUST be set on every word or phrase that is in a different language than the page’s main language.
106 CON-WEB-008-01 WCAG 2.0 1.3.2 Meaningful Sequence A No layout tables Tables MUST not be used for layout purposes. Layout tables are not a direct WCAG 2.0 AA failure, however when a table is linearized it can complicate or confuse the linear order of the content (See WCAG F49 for details).
107 CON-WEB-008-02 WCAG 2.0 1.3.1 Info and Relationships A Markup Tables All data tables MUST use THs and every TH MUST have scope=”col” or “row” set unless any implied relationships would be untrue.  In that case, headers= MUST be used to hard code how headers are read to users.
108 CON-WEB-008-03 WCAG 2.0 1.3.1 Info and Relationships A Identify Tables Data tables MUST be identified for screen readers by including the "title" of the table in its <caption> element, e.g., "Transaction History for x2304"
Note: The caption may be hidden visually with CSS.
109 CON-WEB-008-04 WCAG 2.0 1.3.1 Info and Relationships  A Summarize Table Layout If a data table has more than 4 table headings (THs), the layout/functionality of the table MUST be described in the caption after the "title" of the table. (E.g., Transaction History for x2304: recent transactions in column 1 and details in the next 4 columns. available actions for each transaction are available in column 6”)
Note: The caption may be hidden visually with CSS.
110 CON-WEB-008-05 WCAG 2.0 2.1.1 Keyboard
4.1.2 Name, Role, Value
A, A Table Sorting Sorting state MUST be announced to the screen reader and all sorting controls MUST be keyboard accessible. 
111 CON-WEB-009-01 WCAG 2.0 3.2.4 Consistent Identification AA 5 things Consistent The following MUST be consistent on each page:
• Page title
• Current Navigation menu item
• Progress Indicator / Wizard Step (if present)
• Top-level heading (H1)
• referring link (if present)
112 VIS-WEB-001-01 WCAG 2.0 1.4.4 Resize Text AA Increase text size to 200% Pages MUST be coded to allow users to increase the size of all page content (including text) via built-in browser zoom by at least 200% without text clipping, truncating, or being obscured.
113 VIS-WEB-001-02 WCAG 2.0 1.4.4 Resize Text AA Browser Zoom - Usable Using the built-in browser functionality to zoom all page content to 200% (including text), all interactive content MUST remain fully usable.
114 VIS-WEB-001-03 WCAG 2.0 1.4.4 Resize Text AA Browser Zoom - Informed of Changes Using the built-in browser functionality to zoom all page content to 200% (including text), any user actions that result in on-screen changes MUST meet one of the following criteria:
• A clear visual cue is provided within the viewed area that indicates to the user that the page has changed outside of the currently viewed area based on their action.
• The resulting change occurs within the currently viewed area.
115 VIS-WEB-002-01 WCAG 2.0 1.4.1 Use of Color A Not Only Color If a color difference is used to convey information, that information MUST also be available in text or through some other alternative method.
116 VIS-WEB-003-01 WCAG 2.0 1.4.3 Contrast (Minimum) AA Color Contrast Ratio A color contrast ratio of text, informational images, and images of text to their backgrounds MUST be at least 4.5:1, except if the text is 18 point or 14 point bold or larger, where a ratio of 3:1 is then required.
117 VIS-WEB-003-02 WCAG 2.0 1.4.3 Contrast (Minimum) AA Alternate Style Sheet Color contrast ratio requirements (VIS-WEB-003-01) MUST be met by the site’s default look-tone-feel (LTF) unless an alternate (high-contrast) compliant style sheet is available and an accessible method of activating it is provided. 
E.g., http://www.pearson.com has a high contrast link in their footer.
118 VIS-WEB-004-01 WCAG 2.0 1.4.5 Images of Text AA No images of text Text MUST always be presented using live text and CSS rather than an image of text, except for logos and within pictures where it cannot be avoided (e.g., graphs or screenshots) 
119 VIS-WEB-005-01 WCAG 2.0 1.1.1 Non-text Content A Text Alternatives All non-text content MUST provide text alternatives that provide equivalent information, context, and purpose to the user using the following techniques (as applicable):
• For <img> elements, provide the text alternative using the alt attribute
• For other non-text content (i.e. role="img"), aria-label/labelledby, or visibly hidden text
120 VIS-WEB-005-02 WCAG 2.0 1.1.1 Non-text Content A Decorative Images All non-text content that is decorative, provides no contextual value, or is already defined by surrounding content MUST be hidden from screen reader users using the following techniques (as applicable):
• For <img> elements, provide alt="" (alt null)
• For other non-text content, aria-hidden="true"
121 VIS-WEB-006-01 WCAG 2.0 1.2.2 Captions (Prerecorded)
1.2.4 Captions (Live)
A, AA Captions for Video All video (both live AND prerecorded) content MUST include accurate captions.
122 VIS-WEB-006-02 WCAG 2.0 1.2.3 Audio Description (Prerecorded) A Audio Description for Video If video content provides any information visually that is not described by an accompanying audio track, it MUST also include an Audio Description track that fully explains the visual information.
123 VIS-WEB-006-03 WCAG 2.0 1.2.7 Extended Audio Description (Prerecorded) AAA Extended Audio Description If an Audio Description track cannot fully explain the visual information during gaps in dialog, Extended Audio Description MUST be used (i.e., the video MUST pause at appropriate times to allow for the descriptions to finish) An example of Extended Audio Description can be seen at https://www.youtube.com/watch?v=6C_8NQkgYeQ 
124 VIS-WEB-006-04 WCAG 2.0 1.2.2 Captions (Prerecorded)
1.2.5 Audio Description (Prerecorded)
A, AA Ways to Provide CC and AD Captions and Audio Description MUST be made available to users via one or more of the following methods (both need not use the same method):
• always on, included in the original video
• included as a separate file or track that can be toggled on and off by the user via an accessible mechanism (note: use of Extended Audio Description may complicate this)
• included as a video file and made available via separate link(s) adjacent to the original video link
125 VIS-WEB-006-05 WCAG 2.0 1.2.1 Audio-only & Video-only (Prerecorded) A Transcripts for audio-only/video-only For audio-only and video-only media, a transcript MUST be provided which provides the same information as presented in the original media content.

These materials and steps outlined on this website are provided “AS IS” and are intended for illustrative purposes only. They should not be relied upon for marketing, legal, tax, financial, regulatory or other advice. You are responsible for the legal aspects of any implementation of the concepts illustrated herein. Further, Visa neither makes any warranty or representation as to the completeness or accuracy of this information, nor assumes any liability or responsibility that may result from reliance on such information.  You should not act or rely on such content without seeking the advice of a professional.  All brand names, logos and/or trademarks are the property of their respective owners, are used for identification purposes only, and do not necessarily imply product endorsement or affiliation with Visa.