Accessibility Testing Plan

The VA.gov mobile app development team considers accessibility to be a priority requirement in the design and implementation of the app. The purpose of this document is to outline:

1. The requirements that will guide the the VA.gov Mobile App build
2. The accessibility tools and materials that will be used during testing
3. The testing protocol and steps that will be taken when reviewing the accessibility capabilities in the app

Section 1: Accessibility Requirements & Approach

The following items are based on WCAG 2.2 and Section 508 accessibility standards, organized by product function. Each item description reflects both the requirement and the referenced standard, along with the corresponding implementation approach.

• Items that have “Design” / “Designs” bolded reflect standards that must be facilitated by the design workstream
• Items that have “Programmatically” bolded reflect standards that focus on technical implementation
• Accessibility standards that relate to non-existent functionality in the app are marked N/A. In the event that the app’s design changes to include relevant functionality, these standards will be candidates to prioritize as requirements.
  

Category	WCAG / 508 Section	Implementation Approach
Color	Color contrast (1.4.3_AA) (1.4.6_AAA)	Designs for the the app should consider the following: Normal fonts (< 19px) AA compliant: 4.5:1 AAA compliant: 7:1 Large fonts (19px +) AA compliant: 3:1 AAA compliant: 4.5:1
Color	Color (1.4.1_A)	Designs for the app should not use color as the sole conveyance of information.
Color	Non-text contrast (1.4.11_AA)	Designs of UI components and graphical objects in the app designs that are used to understand the content should have a contrast ratio of at least 3:1.
Headings & Navigation	Heading levels (1.3.1_A)	Designs for each page should have a single h1 and additional headings (h2 - h6) for each section of the page. There are no skipped heading levels. (i.e. the headings don't jump from h1 to h>). Programmatically specify ARIA level for all text headings in React Native.
Headings & Navigation	Info and Relationships (1.3.1_A) (502.3.7) (502.3.8)	Leverage React Native accessible components so that information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
Headings & Navigation	Tables (1.3.1_A) (502.3.3)	All tables should be programmatically identified and the table heading for applicable rows and columns should be announced. N/A: There are currently no complex tables in the designs. If we need to pull in a fancier table than what we can build with react native list views, then we may need to pull in a third party library that is accessible and meets the designs.
Headings & Navigation	Lists (1.3.1_A)	Leverage React Native accessible list component so lists can be programmatically determined.
Headings & Navigation	Page title (2.4.2_A)	Each page on the app should programmatically have a unique title that is descriptive and differentiated. React Native may provide libraries that facilitate this.
Headings & Navigation	Headings and labels (2.4.6_AA)	Headings and labels should describe the topic or purpose and be programmatically determined as such.
Headings & Navigation	Navigation consistency (3.2.3_AA)	Designs for navigation mechanisms that are repeated across several pages should be consistent. (Color, icon, text, location, etc.)
Headings & Navigation	Sensory characteristics (1.3.3_A) (502.3.8)	Designs for pages should not require sensory characteristics such as shape, color, size, visual location, orientation, or sound to be understood or operable.
Headings & Navigation	Bypass Blocks (Skip nav) (2.4.1_A) (c205.2.2)	Provide a means of skipping repeating content (e.g. headers, navigation, bars, etc.). N/A according to section 508 (c205.2.2) and no such navigation exists in the app.
Headings & Navigation	Link purpose in context (2.4.4_A)	Design so that the purpose of each link can be determined by its text (e.g. "Schedule your appointment now") or the context it's surrounded by (e.g. "There are a lot of ways to stay active during the pandemic."). "Click / tap here" should never be used.
Headings & Navigation	Multiple ways to reach each page (2.4.5_AA) (c205.2.2)	Provide more than one way to access content (minimum two ways). N/A according to section 508 (c205.2.2) since this is a non-web format.
Non-text content & media	Text alternatives (1.1.1_A)	Provide text alternatives for any non-text content (e.g. images, non-decorative icons, etc.) so that it can be read by a screen reader or translated into large print, braille, speech, symbols or simpler language.
Non-text content & media	Text alternatives for audio-only and video-only content (1.2.1_A)	Content / API should provide text alternatives for all audio and video content. N/A – No such content exists in the app.
Non-text content & media	Audio descriptions (1.2.5_AA) (503.4.2)	Audio descriptions should be provided for all pre-recorded video content. N/A – No such content exists in the app.
Non-text content & media	Video & live video captions (1.2.2_A & 1.2.4_AA) (503.4.1)	Content / API should provide captions for pre-recorded and live video content. N/A – Use native audio / video player from OS if needed and possible.
Non-text content & media	Audio controls (1.4.2_A) (503.4)	Design so that all audio content has a mechanism to start, stop and adjust volume independent of the system. N/A – Use native audio / video player from OS if needed and possible.
Non-text content & media	Pause, stop, hide - Video & animation controls (2.2.2_A)	Design so that all media content has a mechanism to start, stop and hide. N/A – Use native audio / video player from OS if needed and possible.
Non-text content & media	Flashing content (2.3.1_A)	Designs should not include content or UI elements that flash more than 3 times per second. Avoid flashing content altogether, if possible.
Non-text content & media	Label in name (2.5.3_A) (502.3.6)	Design UI components with a visual label and ensure that the label is programmatically available in the beginning of the name of the component.
Non-text content & media	Identify Input Purpose - Form labels and instructions (1.3.5_AA & 3.3.2_A) (502.3.6) (502.3.9) (502.3.12)	Leverage React Native accessible form components so the purpose of each input field collecting information about the user can be programmatically determined.
Non-text content & media	Form error identification (3.3.1_A)	Leverage React Native accessible form components so that any errors in filling out a form should be designed descriptive, clearly visible and read programmatically.
Non-text content & media	Input triggers (3.2.2_A)	Designs for the app when changing an input should not cause major changes in page content (i.e. forewarn users if their context will change based on their input).
Non-text content & media	Form error suggestions (3.3.3_AA)	Designs for the app should include error messages that include suggestions on how to fix the error. Leverage React Native accessible form components so suggestions can be read programmatically.
Non-text content & media	Legal, financial and data error prevention (3.3.4_AA)	Designs for the app should enable users to be able to reverse, check or confirm inputs for important data.
Text content	Meaningful reading order (1.3.2_A)	Designs for the app should make sure everything is read in an order that makes sense and is programmatically read. Occasionally, iOS will override the order that elements are read on the screen when using Switch Control / Voice Access or a keyboard. QA will test for this and attempt to find a solution, but this is not always possible to fix.
Text content	Images of text (1.4.5_AA) (502.3.8)	Designs should not use images that are purely text, unless its visual style cannot be accomplished via styled text (e.g. logo text).
Text content	Text spacing (1.4.12_AA)	Design and set up text styles so that: Line height / spacing is at least 1.5 times the font size Paragraph spacing is at least 2 times the font size Letter spacing is at least 0.12 times the font size for serif and slab-serif fonts Word spacing is at least 0.16 times the font size for serif and slab-serif fonts
Text content	Text Resizing (1.4.4_AA)	Design so that it’s possible to resize content significantly (ideally to the max device size). Programmatically, all fonts should scale with the font scaling the user has set in the OS. Please note that on certain device sizes, when a user has display zoom enabled on their device, we can only accommodate text size increases to an extent. Content may become cut off or break out of containers. There is no known fix at this time. Content may also become cut off in native components (usually Android) such as alert boxes when the text size is increased. Using shorter headings and descriptions is recommended to help alleviate this.
Text content	Redundant Entry (3.3.7_A)	Design so that information previously entered by or provided to the user that is required to be entered again in the same process is either: auto-populated, or available for the user to select. Except when: re-entering the information is essential, the information is required to ensure the security of the content, or previously entered information is no longer valid. N/A – No such content exists in the app.
Miscellaneous	Content on Hover or Focus (1.4.13_AA)	Programmatically ensure that where content is suddenly visible, then not visible (e.g. a tool-tip) newly shown content is dismissible, hoverable and persistent. This specifically refers to actions that remove pointer hover or when the keyboard focus triggers additional content.
Miscellaneous	Focus Appearance (2.4.13_AAA)	Programmatically ensure that when the focus indicator is visible, an area of the focus indicator meets all the following: is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states Exceptions: The focus indicator is determined by the user agent and cannot be adjusted by the author, or The focus indicator and the indicator's background color are not modified by the author. N/A due to exceptions (focus indicators are determined by the OS in the app).
Miscellaneous	Focus Not Obscured (2.4.11_AAA)	Programmatically ensure that when a UI component receives focus, no part of the component is hidden by author-created content (e.g. the footer navigation bar).
Miscellaneous	Reflow (1.4.10_AA)	Programmatically ensure that content doesn't require horizontal scrolling when resizing.
Miscellaneous	Time limits (2.2.1_A)	Programmatically ensure that time limits set by the content must be able to be turned off, adjusted, extended, or be longer than 20 hours. If the time limit is essential to the experience, then it is exempt.
Miscellaneous	Status Messages (4.1.3_A) (502.3.14)	Programmatically ensure that users are aware of status changes by declaring status messages through roles or properties. For instance, ensuring that "invalid entry", "saved", or "submitted" is communicated to the user. Design should also communicate a change in status.
Miscellaneous	Dragging Movements (2.5.7_AA)	Programmatically ensure that all functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author. For example, a map should allow users to drag the view of the map around, and the map has up/down/left/right buttons to move the view as well. Design should also avoid creating components where dragging is required.
Miscellaneous	Consistent Help (3.2.6_A)	Design should ensure that if any of the following help mechanisms exist and those mechanisms are repeated on multiple screens, they occur in the same relative order to other screen content, unless a change is initiated by the user: Human contact details; Human contact mechanism; Self-help option; A fully automated contact mechanism. N/A – No such content exists in the app.
Miscellaneous	Accessible Authentication (Enhanced) (3.3.8_AAA)	Programmatically ensure that a cognitive function test (e.g. remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following: Another authentication method that does not rely on a cognitive function test. A mechanism is available to assist the user in completing the cognitive function test.
Device specific	Target Size (2.5.5_AAA)	Design should ensure that target pointer / touch inputs are at least 44px by 44px. Programmatically, React Native accessible components on tap targets will be leveraged.
Device specific	Device orientation (1.3.4_AA)	Design should ensure that the UI supports portrait and landscape mode.
Device specific	Pointer gestures (2.5.1_A) (503.2)	Design so that no inputs require gestures and are possible with taps. 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. Assumption: The only feature that will not have a tap-based alternative is scrolling, and this can be supported by platform capabilities. Both platforms have alternatives available to perform simple gestures (e.g. iOS has Assistive Touch built in.)
Device specific	Pointer cancelation (2.5.2_A)	Programmatically ensure that for functionality that can be operated using a single pointer (or tap), at least one of the following is true: The down-event of the pointer is not used to execute any part of the function; Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion; The up-event reverses any outcome of the preceding down-event; Completing the function on the down-event is essential.
Device specific	Motion Actuation (2.5.4_A)	For a feature that requires device motion (e.g. Face ID), design an alternative way to use that feature that doesn't require device motion. Assumption: A login username and password field is an alternative for Face ID. We are also assuming that taking a picture for document upload is an essential function that can’t be done in an alternative way.
Code	Page language (3.1.1_A)	The default human language of the app should be programmatically determined. Please note: We should be very strategic about our pronunciation overrides. It is generally recommended that you not override the screen reader’s pronunciation and that if a correction is needed, we should try not to overcorrect. However, special cases like forcing “mb” to read out as “megabytes” do occur and should be overridden in all instances.
Code	Name, role, value (4.1.2_A) (502.3.1) (502.3.2) (502.3.4) (502.3.5) (502.3.14)	All custom UI components (e.g. form elements, links, components, etc.) should programmatically have a name, role and value. Design and the accessibility specialist should work with engineering to determine the best name for custom components.
Keyboard	Keyboard focus visibility (2.4.7) (502.3.12)	Programmatically ensure that a keyboard will be supported by OS capabilities. If an element is in focus, it should be clearly visible that it is.
Keyboard	Keyboard focus order (2.4.3_A) (502.3.10)	The tab order should make logical sense. All focusable elements should be read aloud by a screen reader. The tab order cannot be programmatically adjusted through React Native as it does not support indexing, therefore the tab order will be dependent on the visual order. However, we could index components using AccessibilityLabel over the indexes of the map over an array of data. Occasionally, iOS will override the focus order when using a keyboard. QA will test for this and attempt to find a solution, but this is not always possible to fix.
Keyboard	Keyboard access (2.1.1_A) (502.3.11) (502.3.13)	Programmatically ensure that a keyboard will be supported by OS capabilities. All functionality of the content should be operable when using a keyboard.
Keyboard	Keyboard traps (2.1.2_A) (502.3.13)	Programmatically ensure that a keyboard will be supported by OS capabilities. Content should not “trap” keyboard focus (i.e. provide ways to exit modals and widgets using the keyboard).
Keyboard	Character Key Shortcuts (2.1.4_A)	Programmatically ensure that a keyboard will be supported by OS capabilities. Keyboard shortcuts must be able to be turned off, remapped or active only if the component is in focus.
Keyboard	Focus triggers (3.2.1_A)	Programmatically ensure that a keyboard will be supported by OS capabilities. Changing focus should not trigger any unexpected changes to page content.

Section 2: Test Environment

Device Matrix

The MVP will support both iOS and Android devices. Since there is a variance between accessibility capabilities across operating systems, one device will be manually tested from each platform.

These devices will be selected from the Device Matrix based on availability during the development cycle. Specific devices from the device matrix may be used depending on the test case. For instance, when testing text / content resizing capabilities, devices with a smaller screen size should be prioritized.

While additional configurations may exist on other devices (i.e. non-Samsung Android devices), these settings are likely to be driven by personal user preferences and to go beyond fundamental platform accessibility capabilities.

Test Tools

Multiple testing tools will be used to ensure adequate testing coverage. Where possible, platform specific assistive technology will be used to inspect accessibility properties that manifest differently across platforms.

• Voiceover (iOS) and Talkback (Android) will be used to test Screen Reader capabilities
• Bluetooth keyboards^* will be used to test keyboard operability.
  • The type of bluetooth keyboard will be confirmed once devices are procured.
• Deque mobile app testing for iOS and Android may be used to audit the app as a comprehensive set of functionality is developed.
• If needed, the results of the full app scan will be shared with the 508 Office nearing the end of the development cycle.

Section 3: Testing Protocol

This testing protocol will be used to guide the testing process. This testing plan may be adjusted in cases where a requirement has been de-prioritized or is determined to be unfeasible for MVP.

• In the criteria section, [P] and [F] denote passing and failing criteria, respectively.
  

Requirement Preference	Protocol	Criteria
Color	Visual observation that color is not the only method used to provide information.	[P] If color is used but is not the only method to provide information. [F] If color is the only method used to provide information.
Color Contrast	Use a contrast comparison tool to determine contrast ratio between text and background colors.	[P] if the contrast ratio is 4.5:1 or greater for normal fonts, and 3:1 or greater for 19px+ fonts, when comparing text to background colors. [F] Less than 4:5:1 contrast ratio for normal fonts and 3:1 for large fonts, when comparing text to background colors.
Heading levels, heading and labels	Use a screen reader to: Ensure that there is only h1 on the page Ensure all heading levels are purposeful and in logical order Ensure that no headings are skipped	[P] If there is only one h1 on the page and all heading levels are purposeful, in logical order and no headings are skipped. [F] If any heading is skipped, read in illogical order, not purposeful or there is more than one h1 on the page.
Info and Relationships	Verify that the screen reader describes any visual information that denotes a relationship, e.g. a child-component relationship to a parent-component.	[P] If the user is informed of visually communicated information and relationships [F] If visually communicated information and relationships are not declared to the user
Lists	Ensure that the screen reader describes any list-like components as lists.	[P] If lists are programmatically determined. [F] If lists are not programmatically determined.
Page title	Review each page in the app and ensure that each unique page title is both descriptive and differentiated.	[P] If each page title is unique, descriptive and differentiated. [F] If a page title is misleading or undescriptive
Sensory characteristics	Visually inspect pages for any items that require characteristics like shape, color, size, visual location, orientation, or sound to be understood or operable.	[P] If all components and pages are understood and operable without needing shapes, colors, size, visual locations, orientations or sounds. [F] If pages require any shape, color, size, visual location, orientation, or sound to be understood or operable.
Text alternatives	Review any non-text content with the screen reader to ensure it has a text alternative.	[P] User is able to interact with non-text content by way of text alternatives. [F] User has no alternative for non-text content.
Flashing content	N/A – The app does not contain any flashing content. In the event this is added, the tester will ensure that any flashing content does not flash more than 3 times per second (3 Hz.)	[P] No flashing content or if there is, it flashes 3 times per second or less. [F] Flashing content > 3 times per second.
Label in name	Review all components with visual labels and ensure the name of the label either matches or is part of the accessible name that is read by the screen reader.	[P] The label of the component either matches or is part of the accessible name. [F] The label name is not included in the accessible name or this content is repeated by the screen reader.
Identify Input Purpose - Form labels and instructions	Use the screen reader and visual observation to ensure all fields collecting information are well labeled so the user can easily tell what is needed.	[P] Purpose for each input field for information collection from the user is easily determined. [F] Input field does not clearly convey the information needed.
Form error identification	Use the screen reader and visual observation to verify that any form entry or submission errors are clearly conveyed to the user. In cases where the app automatically corrects an entered value, the constraint is also communicated.	[P] Screen reader clearly informs users of errors that have occurred during entry or submission. [F] Error messages do not exist, or the screen reader fails to read errors appearing during entry or submission.
Input triggers	Visually observe that filling out form fields will not change the content of the page or form in any major way and that any change that does occur is communicated to the user.	[P] Filling in a form causes no changes in page content. [P] Filling in a form causes a minor change in page content, but is communicated to a user. [F] Input by the user causes major structural changes to the form or page and this change is not communicated to a user.
Form error suggestions	Use the screen reader and visual observation while generating errors to ensure that the user is given clear suggestions on how to fix their input.	[P] Input errors are accompanied by suggestions on how to fix the error. [F] Upon entering information that results in an error, the user does not receive clear suggestions on how to fix the error.
Legal, financial and data error prevention	On the direct deposit page (and any additional pages that are added in the future that require legal or financial data input), ensure that a user can do at least one of the following: Review the information they’ve entered Confirm that the information they’ve entered is correct Reverse or change the information they’ve entered after submission	[P] The user is able to review, confirm, reverse, or change financial and legal inputs. [F] The user is unable to do any of the aforementioned actions and all legal and financial data inputs are final.
Meaningful Reading Order	Use the screen reader to ensure page content is read in a logical order. Occasionally, iOS will override the focus order when using Switch Control / Voice Access or keyboard. QA should test for this and attempt to find a solution, but this is not always possible to fix.	[P] Content is read in a logical order. [F] Content is not read in a logical order and jumps around.
Images of Text	Use visual observation to verify images are not purely text. If images of text do exist, determine whether this is essential to the information being conveyed (e.g. a logo).	[P] Images are not purely text (unless it can’t be accomplished via styled text). [F] Image is purely text despite there being a viable alternative.
Text Spacing	Use inspection tools to verify the following: Line height / spacing is at least 1.5 times the font size. Paragraphs are at least 2 times the font size. Letter spacing is at least 0.12 times the font size. Word spacing is at least 0.16 times the font size.	[P] Line height / spacing is at least 1.5 times font size, paragraphs are at least 2 times font size, letter spacing is at least 0.12 times font size, word spacing is at least 0.16 times font size. [F] Line height / spacing is less than 1.5 times font size, paragraphs are less than 2 times font size, letter spacing is less than 0.12 times font size, word spacing is less than 0.16 times font size.
Text Resizing	Use the OS font scaling settings to verify the user is able to resize content to the maximum device size. Note: The header and navigation bar will not be reviewed for this criteria, as resizing these components significantly would make them unusable. On certain device sizes, when a user has display zoom enabled on their device, we can only accommodate text size increases to an extent. Content may become cut off or break out of containers. There is no known fix at this time. Content may also become cut off in native components (usually Android) such as alert boxes when the text size is increased. If this occurs, a recommendation may be made to reduce the length of the copy in the container.	[P] Text may be resized with no loss of functionality. [F] User experiences some loss of functionality when text is resized.
Time Limits	N/A as no time limits currently exist. In the event this is added, the tester will use the screen reader and visual observation to ensure any time limits under 20 hours and set by the content can be turned off, adjusted, or extended.	[P] If there are no time limits or any time limits existing may be adjusted, extended, or the limit is longer than 20 hours. [F] If there is a time limit (other than essential) that may not be adjusted, extended or is longer than 20 hours.
Status Messages	Use the screen reader and visual observation to check that any errors or other status messages (like “saved” or “submitted”) are communicated to the user.	[P] All status messages are communicated to the user and may be seen or heard with a screen reader. [F] Status messages are not communicated to the user or read by the screen reader.
Target Size	Use the inspection tool to verify all touch point / target pointer inputs on a page are at least 44px by 44px in size.	[P] If all touch points on a page are 44px by 44px or larger. [F] If any touch point on a page is smaller than 44px by 44px.
Pointer Gestures	By observation, verifying no inputs (other than scrolling) requires any gestures other than tapping.	[P] If all components (e.g. buttons, tabs, or sliders) may be operated with a simple tapping gesture to operate. [F] If a component besides scrolling requires a sliding or path-based gesture to operate.
Pointer Cancellation	By observation, verify that any functionality that can be operated using a single pointer has at least one of the following true: No down-event, abort or undo No up-reversal (unless it is essential)	[P] There is no down-event, abort, undo or there is no up-reversal (unless it is essential). [F] There are down-events, aborts, undos and up-reversals that are not essential.
Motion Actuation	By observation, verify that there are alternatives to any feature requiring device motion (like Face ID) and that there is no required shaking or tilting of the device, etc. Note: Taking a picture with the device is an exception because it is an essential function with no alternative.	[P] If all functions using motion have an alternative that doesn’t require shaking or tilting of the device. [F] If shaking or tilting of the device is necessary without an alternative (other than taking pictures).
Page Language	N/A since the app only supports English. If an app supports multiple languages, ensure that the language can be accurately identified by the device by checking that: Screen readers can load the correct pronunciation rules. Characters and scripts are displayed correctly. Media players can show captions correctly.	[P] Page is written in human language and is easily read, both visually and with the screen reader. Media players and characters/ scripts are also correct. [F] Page is unable to be read visually or by screen reader. Characters and script do not match the selected language.
Name, Role, Value	Use the screen reader and visual observation to verify all custom UI components have a discernible, logical name and role (and value when applicable).	[P] The name, role, and value when applicable, of each custom component are clear and read by the screen reader. [F] Any custom UI components are missing a name, role or value.
Keyboard Focus Visibility	Use a keyboard connected to the device and verify ability to tab through page elements, ensuring that focus is clearly visible.	[P] If focus is clearly visible while tabbing through elements. [F] If focus is difficult to determine while tabbing through elements.
Keyboard Focus Order	Use a keyboard connected to the device to tab through page elements. Verify the following: Tab order is logical. All focused elements are read aloud by the screen reader. Occasionally, iOS will override the focus order when using a keyboard. QA should still test for this and attempt to find a solution, but this is not always possible to fix.	[P] If tab order is in logical order AND all elements are read aloud by screen reader. [F] If tab order jumps around the screen in an illogical order OR all elements are not read aloud.
Keyboard Access	Use a keyboard connected to the device and verify that all functionality of content is accessible and operable through use of the keyboard.	[P] If all elements on the screen are accessed and operable through the keyboard. [F] If any element on the screen may not be operable through the keyboard.
Keyboard Traps	Use a keyboard connected to the device and verify that all functions of the page are operable without becoming trapped in any particular element, modal, or widget (e.g. getting stuck and not able to leave the element).	[P] If a user is able to leave or exit all operations on the screen without becoming trapped or “stuck”. [F] If a user gets caught in any sort of loop or element that they may not exit using any key or combination of keys on the keyboard.
Character Key Shortcuts	Use a keyboard connected to the device to verify that any custom keyboard shortcuts can be turned off, remapped or only active while the component is in focus.	[P] If a custom keyboard shortcut is able to be turned off, remapped or is only active when the component is in focus [F] If a custom keyboard shortcut cannot be modified or is active beyond in-focus components.
Focus Triggers	Use a keyboard connected to the device to tab through and verify that no unexpected changes appear to page content by simply changing focus.	[P] If no unexpected changes occur when changing focus [F] If any unexpected changes occur to page content when changing focus
Redundant Entries	N/A – Complex forms requiring redundant entries do not currently exist in the app. In the future, if forms with redundant entries are added and required, ensure that the field can be: auto-populated, or available for the user to select. Except when: re-entering the information manually is essential, the information is required to ensure the security of the content, or previously entered information is no longer valid.	[P] Redundant form entries can be auto-populated or are available to select. [P] It is required that a redundant form entry be manually entered due to the security of the content, the previous information entered is invalid, or entering the information again manually is essential. [F] A user must manually input information into redundant form fields without the ability to auto-populate or select and it is not due to invalidity, secure content, or otherwise essential to manually entire.
Focus Not Obscured	Use visual observation to verify that when a UI component receives focus, no part of the component is hidden by other content (e.g. the footer navigation bar).	[P] No focusable elements are obscured or hidden by other content / elements. [F] A focusable element is hidden or obscured behind / below another element.
Consistent Help	N/A – A help feature does not currently exist in the app. If a help feature is added to the app in the future and is included / repeated on multiple screens, visually verify that it occurs / appears in the same relative order and / or area on each screen.	[P] A help mechanism exists and appears in the same relative area on each screen of the app. [F] A help mechanism exists and does not appear in the same relative area on each screen of the app.
Accessible Authentication	Verify that a cognitive function test (e.g. remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following: Another authentication method that does not rely on a cognitive function test. A mechanism is available to assist the user in completing the cognitive function test. Note: We do not currently have control over the login process and cannot ensure compliance with this guideline.	[P] The login process does not only require a cognitive function test to login. If a cognitive function test is present, it provides alternatives. [F] The login process requires a cognitive function test to login and there is no other alternative to bypass and / or gain assistance in completing the test to login.