VGAR Test Procedures

VGAR Overview Requirements Test Procedures PDF Tools

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.

Req Order Req ID Name Requirement Related Spec Spec Mapping WCAG Level
1 PAG-WEB-001-01 Valid Code An automated HTML validation tool does not return any issues related to incomplete start and end tags, improperly nested elements, or duplicate IDs and/or attributes. WCAG 2.0 4.1.1 Parsing A
2 PAG-WEB-002-01 Doctype A valid doctype MUST be set for all pages WCAG 2.0 4.1.1 Parsing A
3 PAG-WEB-003-01 Accurate Title An accurate and descriptive page <title> title MUST be included on every page or view. WCAG 2.0 2.4.2 Page Titled A
4 PAG-WEB-003-02 Unique Title The page title MUST be unique and conform to a consistent structure among the other pages. WCAG 2.0 2.4.2 Page Titled A
5 PAG-WEB-004-01 Lang Attribute The applicable language MUST be defined on every page, inside the html tag. WCAG 2.0 3.1.1 Language of Page A
6 PAG-WEB-005-01 Iframe Use iframes SHOULD only be used if absolutely necessary due to potential confusion for screen reader users. WCAG 2.0 1.3.1 Info and Relationships

 A
7 PAG-WEB-005-02 Iframe Titles iframes intended for user interaction MUST have a unique, descriptive, and consistent <title> so users can identify them easily. WCAG 2.0 4.1.2 Name, Role, Value A
8 PAG-WEB-005-03 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")		 WCAG 2.0 1.3.1 Info and Relationships

 A
9 PAG-WEB-008-01 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;
  }		 WCAG 2.0 1.3.1 Info and Relationships

 A
10 PAG-WEB-008-02 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"		 WCAG 2.0 1.3.1 Info and Relationships

 A
11 PAG-WEB-008-03 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>		 WCAG 2.0 1.3.1 Info and Relationships

 A
12 PAG-WEB-009-01 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.).  WCAG 2.0 4.1 Compatible A
13 PAG-WEB-009-02 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 without receiving focus. WCAG 2.0 4.1.3 Status Messages A
14 PAG-WEB-009-03 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. WCAG 2.0 4.1.3 Status Messages A
15 PAG-WEB-009-04 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.  WCAG 2.0 2.4.2 Page Titled A
16 PAG-WEB-009-05 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.  WCAG 2.0 4.1.2 Name, Role, Value A
17 PAG-WEB-009-06 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". WCAG 2.0 1.3.2 Meaningful Sequence A
18 PAG-WEB-009-07 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. WCAG 2.0 1.3.1 Info and Relationships A
19 PAG-WEB-009-08 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 landmarks  of the same type on the screen, each supported screen reader MUST accurately identify each uniquely by reading both the role and label. WCAG 2.0 4.1.2 Name, Role, Value A
20 PAG-WEB-009-09 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 ANDI. WCAG 2.0 1.3.1 Info and Relationships A
21 PAG-WEB-009-10 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. WCAG 2.0 4.1.2 Name, Role, Value A
22 PAG-WEB-010-01 Use an Automated Testing Tool When run against the page, the automated validation tool MUST NOT report any errors. WCAG 2.0; WCAG 2.1 NA AA
23 NAV-WEB-001-01 Keyboard Support All functionality and content MUST be available to users via the keyboard only (without a mouse) without requiring specific timing of keystrokes. WCAG 2.0 2.1.1 Keyboard A
24 NAV-WEB-001-02 Mouse Hover and Keyboard Focus are Equivalent Content which is hidden until it receives mouse hover and then becomes visible MUST also be shown when it receives keyboard focus and hidden again when focus is removed. WCAG 2.0 2.1.1 Keyboard
1.4.13 Content on Hover or Focus		 A
25 NAV-WEB-001-03 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.

If 3rd party content is not VGAR compliant then the vendor should be notified and a fix should be requested. If the vendor is not able/willing to fix then the 3rd party content MUST be phased out and replaced with an accessible solution.		 WCAG 2.1 NA AA
26 NAV-WEB-001-04 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.  WCAG 2.0 2.1.2 No Keyboard Trap A
27 NAV-WEB-001-08  Content on Hover or Focus For tooltips and components that show hidden content when they receive keyboard or pointer focus and hidden after removal of focus ensure they are dismissible, hoverable, and persistent. WCAG 2.1 1.4.13 Content on Hover or Focus AA
28 NAV-WEB-001-09 Pointer and Multipoint Gestures An action that is performed by a 'path-based gesture' or multipoint gesture MUST also be completable using a single pointer gesture and a keyboard or alternative input device. WCAG 2.1 2.5.1 Pointer Gestures A
29 NAV-WEB-002-01 Visible Keyboard Focus A highly visible cue MUST always be presented to indicate keyboard focus. The focus indicator MUST maintain a minimum 3:1 contrast ratio against the background at all times to be considered highly visible. WCAG 2.0 2.4.7 Focus Visible AA
30 NAV-WEB-002-02 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).

List of Composite Control Exceptions:
- Options in a List box
- Menu items in a Menu or menu bar
- Tab elements in a set of Tabs
- Tree items in a Tree View		 WCAG 2.0 1.4.1 Use of Color 2.4.7 Focus Visible AA
31 NAV-WEB-002-03 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. WCAG 2.0 2.4.3 Focus Order A
32 NAV-WEB-003-01 Appropriate Use of Landmark Regions The page MUST have a 'Main' landmark region defined at a minimum and Banner, Navigation, Search, Complementary, and ContentInfo roles are present if these content types are present in the page.

 WCAG 2.0 2.4.1 Bypass Blocks A
33 NAV-WEB-003-02 HTML5 Sections Don't Interfere IF HTML5 Section elements are present, the landmark roles automatically created for them do not interfere with any other landmark region roles present in the page by introducing redundant landmark regions or regions with the same role and non-unique names. WCAG 2.0 2.4.1 Bypass Blocks A
34 NAV-WEB-003-03 Keep All Content in Appropriate Regions All rendered content MUST be within the appropriate landmark region AND the Main landmark MUST contain all of the primary page content AND no blocks of content that repeat on multiple pages are within the Main landmark. WCAG 2.0 2.4.1 Bypass Blocks A
35 NAV-WEB-003-04 Redundant Landmarks Have Unique Names If a page has multiple landmarks of the same type (e.g., Main Nav and Sub Nav), those regions MUST have unique names applied using an appropriate naming technique AND the landmark role type Must not be included in the name.  WCAG 2.0 2.4.6 Headings and Labels A
36 NAV-WEB-003-05 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 link may be visually hidden until it has focus. WCAG 2.0 2.4.1 Bypass Blocks A
37 NAV-WEB-003-06 Skip to Main Content Link A "skip to main 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. WCAG 2.0 2.4.1 Bypass Blocks A
38 NAV-WEB-003-07 Headings have Priority over Sections Headings provide semantic structure not available in <section> elements. However, <section> elements MAY be used on a page when necessary. If HTML5 sections are used within the "Main" ARIA Landmark role, then they MUST follow the page's heading hierarchy. WCAG 2.0 1.3.1 Info and Relationships A
39 NAV-WEB-004-01 No Access Keys Access keys MUST not be used. WCAG 2.0 2.1.1 Keyboard A
40 NAV-WEB-004-02 Single character keyboard shortcuts If a single character shortcut is used then users MUST have the option to either turn it off or remap it to one or more non-printable keyboard characters.
-OR-
Make sure the single character shortcut is only active when the component it affects has focus.		 WCAG 2.1 2.1.4 Character Key Shortcuts A
41 NAV-WEB-005-01 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, unless the site is composed of 4 pages or fewer:
• 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		 WCAG 2.0 2.4.5 Multiple Ways AA
42 NAV-WEB-006-01 Same Relative Order  Components that appear on multiple pages MUST appear in the same relative order on every page. WCAG 2.0 3.2.3 Consistent Navigation  AA
43 NAV-WEB-006-02 Name Consistently Consistent labels, names, and text alternatives MUST be used for content that has the same functionality. WCAG 2.0 3.2.4 Consistent Identification AA
44 NAV-WEB-006-03 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. WCAG 2.0 2.4.9 Link Purpose (Link Only) AAA
45 NAV-WEB-006-04 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"		 WCAG 2.0 2.1.2 No Keyboard Trap A
46 NAV-WEB-007-01 Pagination is Navigation Pagination controls MUST have the attribute role="navigation". WCAG 2.0 4.1.2 Name, Role, Value A
47 NAV-WEB-007-02 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". WCAG 2.0 4.1.2 Name, Role, Value A
48 NAV-WEB-008-01 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"). WCAG 2.0 2.4.8 Location AAA
49 NAV-WEB-008-02 Wizard Info in Title / H1 Any Process or Wizard Step Indicator information MUST be included in the page title and H1. WCAG 2.0 2.4.8 Location AAA
50 INT-WEB-001-01 Fully Descriptive Control Labels Controls and inputs 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).  WCAG 2.0 2.4.6 Headings and Labels A
51 INT-WEB-001-02 Label Controls (or title) Controls and form elements MUST include a label AND the label must include formatting if a specific format is required.  WCAG 2.0 3.3.2 Labels or Instructions AA
52 INT-WEB-001-03 Hide Part of Labels Some or all of a label MAY be hidden with CSS if the visual presentation provides the necessary context. WCAG 2.0 3.3.2 Labels or Instructions AA
53 INT-WEB-001-04 Associate Label with Control 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>", aria-labelledby OR an aria-label. WCAG 2.0 1.3.1 Info and Relationships A
54 INT-WEB-001-05 Group Controls Using Fieldsets If there is more than one distinct group of related form controls on a page, the related controls MUST be grouped programmatically. This may be done using either fieldset/legend or ARIA group role/text container. Text describing the logical grouping MAY be hidden off-screen if it isn't visually necessary. WCAG 2.0 1.3.1 Info and Relationships A
55 INT-WEB-001-07 Required Fields Required fields/controls MUST use the aria-required="true" attribute. They MUST also be communicated in text either at the beginning of the form or in-line.

Groups of checkboxes SHOULD not have the aria-required attribute and the required state should be indicated in text either at the beginning of the form, stating all fields are required, or in the group's fieldset legend instead.		 WCAG 2.0 1.3.1 Info and Relationships  A
56 INT-WEB-001-08 Use aria-describedby Helper text MUST be programmatically associated with a form control using aria-describedby="<ID of helper texts container>". WCAG 2.0 1.3.1 Info and Relationships A
57 INT-WEB-001-09 Specify Input Purpose Programmatically If an input field is used to collect information about the user and the field supports autocomplete then the input field's purpose is identified programmatically. WCAG 2.1 1.3.5 Identify Input Purpose AA
58 INT-WEB-001-10 Visible and Programmatic Label Consistency If a control's visual label differs from the programmatic/accessible name value then the programmatic/accessible name value includes the visual label text at the beginning of the text string. WCAG 2.1 2.5.3 Label in Name A
59 INT-WEB-002-01 Check for Errors All pages that accept user input MUST check for errors and allow the user to correct them through in-line and post-submit validation and messaging as detailed in INT-002-03 and INT-002-04. Where users are prevented from submitting a form with errors, in-line validation is required but post-submit validation is not. Where users are able to submit a form with errors, post-submit validation is required. WCAG 2.0 3.3.1 Error Identification
3.3.3 Error Suggestion		 A
60 INT-WEB-002-02 Summary Before Submit If user input is collected across multiple pages in order to execute a transaction of some kind, at least one of the following MUST be true:
presented with a summary of the input before submitting:
a. submissions are reversible
b. data entered by the user is checked for input errors, and the user is given an opportunity to correct them
c. The user can review, confirm, and correct information before finalizing the submission		 WCAG 2.0 3.3.4 Error Prevention AA
61 INT-WEB-002-03 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. WCAG 2.0 4.1.2 Name, Role, Value A
62 INT-WEB-002-04 Highlight In-line Errors Visually When an error is detected using in-line validation, highlight the field (e.g., with a bold red border, error icon with proper alternative text) and place error helper text near it. WCAG 2.0 3.3.1 Error Identification
3.3.3 Error Suggestion		 A, AA
63 INT-WEB-002-05 In-line Error Messaging for Screen Reader 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. WCAG 2.1 4.1.3 Status Messages AA
64 INT-WEB-002-06 In-line Error Validation for Screen Reader When an error is detected using client side validation the following MUST be programmatically accommodated:

1. set aria-invalid="true"
2. add the ID of the error helper text container to the aria-describedby attribute if present or add an aria-describedby attribute if not 

Example: aria-describedby="helpertext" changes to aria-describedby="error_helpertext helpertext".		 WCAG 2.0 WCAG 2.0 A - 3.3.1 Error Identification

WCAG 2.0 AA - 3.3.3 Error Suggestion		 AA
65 INT-WEB-002-07 Post-Submit Errors

When an error is detected using validation after the user submits the form (i.e., multiple errors may be detected at once):



  1. Use the screen reader to submit the form containing fields with errors
  2. Confirm that the screen reader announces the error message added to the top of the page on page/view refresh
  3. Confirm that focus is automatically set on the first invalid form control
  4. Confirm that moving to each field with an error causes the screen reader to announce that the field is invalid along with the error helper text
  5. Confirm that in-line field errors are identified correctly per INT-002-03, INT-002-04, INT-002-05, and INT-002-06
  6. Inline errors SHOULD disappear when they have been corrected in the form.

 

 WCAG 2.0 WCAG 2.0 A - 3.3.1 Error Identification

WCAG 2.0 AA - 3.3.3 Error Suggestion

WCAG 2.1 AA - 4.1.3 Status Messages		 AA
66 INT-WEB-003-01 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. WCAG 2.1 4.1.3 Status Messages A
67 INT-WEB-003-02 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. WCAG 2.1 4.1.3 Status Messages A
68 INT-WEB-004-01 Modal Aria Usage Modal windows MUST have the role attribute on the modal container set to role=“dialog” AND the attribute aria-modal="true". WCAG 2.0 4.1.2 Name, Role, Value A
69 INT-WEB-004-02 Modals Have Titles Modal windows MUST have aria-labelledby="id of dialog-title" where dialog-title would be the modal’s title (e.g., main heading in modal). WCAG 2.0 4.1.2 Name, Role, Value A
70 INT-WEB-004-03 Modals Have Descriptions Modal windows SHOULD have aria-describedby="dialog-desc" where dialog-desc is some helpful information that is above the first focusable element. WCAG 2.0 1.3.1 Info and Relationships A
71 INT-WEB-004-04 Modals Trap Focus Modal windows MUST trap focus inside the modal. WCAG 2.0 2.4.3 Focus Order A
72 INT-WEB-004-05 Modals Set Focus Modal windows MUST have focus set to an appropriate location based on the content presented in the modal.

Where to Place Focus:
- If modal has form fields place focus in first field
- If modal is text only with multiple paragraphs action buttons below the text place focus on the first paragraph or heading
- If modal is text only with a small amount of text (e.g. a few sentences) with action buttons place focus on the first button
- Initial focus may also be set to the modal container  		 WCAG 2.0 2.4.3 Focus Order A
73 INT-WEB-004-06 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. WCAG 2.0 2.4.3 Focus Order A
74 INT-WEB-004-07 Modals Prevent Clicks Outside Modal windows MUST prevent mouse-clicks that occur outside the modal from having any effect on the modal. WCAG 2.0 2.4.3 Focus Order A
75 INT-WEB-004-08 Modal Main Heading If a heading is used in a modal dialog the first heading level MUST be H2 followed by appropriate heading levels. WCAG 2.0 1.3.1 Info and Relationships A
76 INT-WEB-004-09 Modals Close on ESC Modal windows MUST have the <ESC> keyboard event set to close the modal. WCAG 2.0 2.1.1 Keyboard A
77 INT-WEB-004-10 Modals Restore Focus Modal windows MUST restore focus to their triggering element when modal is closed. WCAG 2.0 2.4.3 Focus Order A
78 INT-WEB-005-01 Don't Use onFocus or onInput Events The onFocus and onInput events MUST not be utilized to perform any actions for the user or cause a change of context for the user that would be missed or cause confusion. WCAG 2.0 3.2.1 On Focus A
79 INT-WEB-005-02 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. WCAG 2.0 3.2.2 On Input A
80 INT-WEB-005-03 Warn Users in Text and With describedby If 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.		 WCAG 2.0 3.2.2 On Input A
81 INT-WEB-005-04 Activate Only on Up Event Actions completed with mouse or touch input MUST not use the down-event to execute any part of the function.
-OR-
Make sure there is a way for the user to abort or undo the action.
-OR-
Allow the up-event to reverse any outcome of the preceding down-event		 WCAG 2.1 2.5.2 Pointer Cancellation A
82 INT-WEB-006-01 Links vs Buttons User interface elements defined as links (anchor elements) SHOULD behave as links and user interface elements defined as buttons SHOULD behave as buttons:
- Links reference or move the user to another location
- Buttons trigger an action or event		 WCAG 2.0 4.1.2 Name, Role, Value;
1.3.1 Info and Relationships		 A
83 INT-WEB-006-02 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. WCAG 2.0 2.4.4 Link Purpose (In Context) A
84 INT-WEB-006-03 Valid Link href Attribute Links MUST contain a valid href attribute value and MUST  not point to "javascript:void(0);" nor "#". WCAG 2.0 4.1.2 Name, Role, Value A
85 INT-WEB-006-04 Links Opening in New Tabs If a link opens in a new browser tab or window an aria-label AND visual cue MUST be added to inform users of this interaction. WCAG 2.0 3.2.4 Consistent Identification AA
86 INT-WEB-007-01 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		 WCAG 2.0 2.2.2 Pause, Stop, Hide A
87 INT-WEB-007-02 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.		 WCAG 2.0 1.4.2 Audio Control A
88 INT-WEB-008-01 No Blinking or Flashing Content that blinks or flashes MUST never be used. WCAG 2.0 2.3.1 Three Flashes or Below Threshold A
89 INT-WEB-009-01 Warn About Timeout Users MUST be warned prior to when a session times out and expires. WCAG 2.0 2.2.1 Timing Adjustable A
90 INT-WEB-009-02 Extend 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"). WCAG 2.0 2.2.1 Timing Adjustable A
91 INT-WEB-010-01 Name Custom Controls If 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. WCAG 2.0 4.1.2 Name, Role, Value A
92 INT-WEB-010-02 Emulate Native 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. role, state, value, and properties).
 WCAG 2.0 4.1.2 Name, Role, Value A
93 INT-WEB-010-03 Custom Control Keyboard 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. WCAG 2.0 2.1.1 Keyboard A
94 INT-WEB-010-04 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).  WCAG 2.0 4.1.2 Name, Role, Value A
95 INT-WEB-011-01 Flexible Orientation Content MUST adapt to the device orientation when orientation is changed from portrait to landscape unless a specific orientation is required for use of the page. WCAG 2.1 1.3.4 Orientation AA
96 INT-WEB-011-02 Motion Control  If functionality can be operated or activated by device or user motion then it can also be operated or activated through UI components AND motion actuation can be turned off to avoid unintentional activation by the user. WCAG 2.1 2.5.4 Motion Actuation A
97 CON-WEB-001-01 Use Headings (H1 etc.)
  1. Open ANDI > Structures > Headings > View Headings List
  2. View all headings instances listed below the 'View headings list' button
  3. Confirm that each page organizes content using headings (e.g., H1, H2, etc.) and that all content which serves as a heading visually and structurally is also exposed as a heading programmatically.
  4. Confirm that the page headings accurately describe their sub-content
 WCAG 2.0 1.3.1 Info and Relationships  AA
98 CON-WEB-001-02 Use a Single Descriptive H1 Each page MUST have only one H1 which is descriptive of the overall page topic/purpose. The H1 and the page title SHOULD be similar and consistent.  WCAG 2.0 2.4.6 Headings and Labels AA
99 CON-WEB-001-03 H1 at Top of Main The H1 MUST be within and at the top of the Main ARIA Landmark, with no content above it. WCAG 2.0 1.3.2 Meaningful Sequence A
100 CON-WEB-001-04 Sequential Headings Headings MUST be implemented sequentially in order without skipping levels. (i.e., Heading 1, then Heading 2, then Heading 3 and so on). This applies to ascending and descending heading levels. Headings of the same level may be repeated (e.g., H2, H2, H2, etc.). WCAG 2.0 1.3.2 Meaningful Sequence A
101 CON-WEB-002-01 Use Correct Semantic Markup Whenever content conveys information through presentation of text, appropriate semantic markup (e.g., em, strong, cite, blockquote, sub, and sup) MUST be used.   WCAG 2.0 1.3.1 Info and Relationships A
102 CON-WEB-003-01 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. WCAG 2.0 1.3.2 Meaningful Sequence A
103 CON-WEB-003-02 Remove or Park "hidden" Content at the Bottom "Hidden" content being "parked" for later use/display (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. WCAG 2.0 1.3.2 Meaningful Sequence A
104 CON-WEB-004-01 Paragraph Markup for Text Paragraphs MUST be marked up as paragraphs. WCAG 2.0 1.3.1 Info and Relationships A
105 CON-WEB-004-02 Group Items With Lists Groups of items (e.g., a navigation menu or group of tabs) MUST be marked up as a list. WCAG 2.0 1.3.1 Info and Relationships A
106 CON-WEB-005-01 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. WCAG 2.0 2.4.4 Link Purpose A
107 CON-WEB-006-01 Instructions Don’t Rely on Visual Cues Instructions MUST never refer solely to visual cues such as size, shape, color, or spatial directions. WCAG 2.0 1.3.3 Sensory Characteristics A
108 CON-WEB-006-02 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. WCAG 2.0 1.3.3 Sensory Characteristics A
109 CON-WEB-007-01 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. WCAG 2.0 3.1.2 Language of Parts AA
110 CON-WEB-008-01 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). WCAG 2.0 1.3.2 Meaningful Sequence A
111 CON-WEB-008-02 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. WCAG 2.0 1.3.1 Info and Relationships A
112 CON-WEB-008-03 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.		 WCAG 2.0 1.3.1 Info and Relationships A
113 CON-WEB-008-04 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. Actions for each transaction are available in column 6.”)
Note: The caption may be hidden visually with CSS.		 WCAG 2.0 1.3.1 Info and Relationships A
114 CON-WEB-008-05 Table Sorting Sorting state MUST be announced to the screen reader and all sorting controls MUST be keyboard accessible.  WCAG 2.0 2.1.1 Keyboard
4.1.2 Name, Role, Value		 A
115 CON-WEB-009-01 Consistent Context Cues 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)		 WCAG 2.0 3.2.4 Consistent Identification AA
116 VIS-WEB-001-01 Allow Text Resizing Pages MUST be coded to allow users to increase the font size of all page content without text clipping, truncating, or being obscured.  WCAG 2.0 1.4.4 Resize Text AA
117 VIS-WEB-001-02 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. WCAG 2.0 1.4.4 Resize Text AA
118 VIS-WEB-001-03 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.		 WCAG 2.0 1.4.4 Resize Text AA
119 VIS-WEB-001-04 Content Reflow

When viewport size is constrained to 320 CSS pixels wide:

  • there is no loss of information, meaning, or functionality and any status messages are presented in the resized zoomed viewport.
  • user is only required to scroll VERTICALLY in one dimension to view or find the content
    • EXCEPT when the content requires a two-dimensional layout for meaning like tables, maps, or diagrams.

When viewport size is constrained to 256 CSS pixels high:

  • there is no loss of information, meaning, or functionality and any status messages are presented in the resized zoomed viewport.
  • user is only required to scroll HORIZONTALLY in one dimension to view or find the content
    • EXCEPT when the content requires a two-dimensional layout for meaning like tables, maps, or diagrams.
 WCAG 2.1 1.4.10 Reflow AA
120 VIS-WEB-001-05 User Text Styling User text style settings do not cause a loss of content when:

- Line height (line spacing) to at least 1.5 times the font size;
- Spacing following paragraphs to at least 2 times the font size;
- Letter spacing (tracking) to at least 0.12 times the font size;
- Word spacing to at least 0.16 times the font size.		 WCAG 2.1 1.4.12 Text Spacing AA
121 VIS-WEB-002-01 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.

Link text may be distinguished from static text through use of color as long as the following are true:

- A 3:1 contrast ratio difference exists between the link text and other static text
- A visual indicator is provided when the link receives focus (e.g. visible underline on hover and keyboard focus)		 WCAG 2.0 1.4.1 Use of Color A
122 VIS-WEB-003-01 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 unless it is a logo or brand name. WCAG 2.0 1.4.3 Contrast (Minimum) AA
123 VIS-WEB-003-02 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.  WCAG 2.0 1.4.3 Contrast (Minimum) AA
124 VIS-WEB-003-03 Contrast for Non-text UI Components User interface components and graphical objects MUST have a contrast ration of at least 3:1 against adjacent colors.  WCAG 2.1 1.4.11 Non-text Contrast AA
125 VIS-WEB-003-04 Support High Contrast All content adapts and supports the user's high contrast mode settings Section 508   NA
126 VIS-WEB-004-01 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). WCAG 2.0 1.4.5 Images of Text AA
127 VIS-WEB-005-01 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		 WCAG 2.0 1.1.1 Non-text Content A
128 VIS-WEB-005-02 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"		 WCAG 2.0 1.1.1 Non-text Content A
129 VIS-WEB-006-01 Captions for Video All video (both live AND prerecorded) content MUST include accurate captions. WCAG 2.0 1.2.2 Captions (Prerecorded)
1.2.4 Captions (Live)		 A
AA
130 VIS-WEB-006-02 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. WCAG 2.0 1.2.3 Audio Description (Prerecorded) A
131 VIS-WEB-006-03 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) WCAG 2.0 1.2.7 Extended Audio Description (Prerecorded) AAA
132 VIS-WEB-006-04 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		 WCAG 2.0 1.2.2 Captions (Prerecorded)
1.2.5 Audio Description (Prerecorded)		 A
AA
133 VIS-WEB-006-05 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. WCAG 2.0 1.2.1 Audio-only & Video-only (Prerecorded) A

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.