WCAG Success Criteria | Conformance Level | Remarks and Explanations |
1.1.1 Non-text Content | Partially Supports | The application supports some images with alt text. Decorative images are marked with empty alt attributes. Continued work on alt text for all images is currently in progress for 2025. |
1.2.1 Audio-only and Video-only (Prerecorded) | Not Applicable | Any audio or video content within the application is uploaded by clients. |
1.2.2 Captions (Prerecorded) | Not Applicable | Any audio or video content within the application is uploaded by clients. |
1.2.3 Audio Descriptions or Media Alternative (Prerecorded) | Not Applicable | Any audio or video content within the application is uploaded by clients. |
1.3.1 Info and Relationships | Supports | The application pages are structured with semantic HTML elements, (e.g., <h1>, <h2>, etc.) following a hierarchy. Form fields have associated <label> elements. Popups and modals have close out buttons that are associated with the dialog for easy navigation and dismissal. |
1.3.2 Meaningful Sequence | Supports | The application is structured with semantic HTML elements (e.g., <h1>, <h2>, <body>, <button>, <form>, <label>, <input>etc.) following a hierarchy to ensure the content is presented in a meaningful sequence. At this time the application does not support keyboard tab, however we're researching this as our product does not rely on a physical or digital keyboard. |
1.3.3 Sensory Characteristics | Partially Supports | The application supports VoiceCommands, VoiceOver/TalkBack, which provide auditory feedback for interactive elements. The application does not rely on sensory characteristics such as shape, size, color or visual location. Since most of the content is created by clients, they are responsible for ensuring additional instructions are provided. However, we are actively exploring where clients might not be able to provide these instructions. |
1.4.1 Use of Color | Partially Supports | The application uses icons and labels to convey information, ensuring that color is not the sole means of communication. Labels are provided alongside color to assist with voice-over technologies, making it clear to users even if they cannot distinguish color. While compliant, we are always exploring ways to improve (e.g. using additional information - errors are marked with an error message.) |
1.4.2 Audio Control | Not Applicable | Any audio or video content within the application is uploaded by clients. Depending the audio or video it will either use the hosted platform player (youtube, soundcloud) or the operating system player which should allow for audio control. |
2.1.1 Keyboard | Not Applicable | Our application does not currently rely on a physical or digital keyboard for general navigation or interaction, however keyboard input is supported when users are inputting information into form fields. Since keyboard use is restricted to specific use cases like form submissions, we do not expect the application to support keyboard navigation at this time. |
2.1.2 No Keyboard Trap | Not Applicable | The application does not rely on a physical or digital keyboard for navigation or interaction. As such, this criteria does not apply. The application uses touch or other methods for user interaction. |
2.1.4 Character Key Shortcuts | Not Applicable | The application does not implement character key shortcuts. |
2.2.1 Timing Adjustable | Not Applicable | The application does not include any time limits or timing mechanisms that require user interaction. Users are not subject to time constraints within the application, and therefore, the need for adjustable or extendable time limits does not arise. |
2.2.2 Pause, Stop, Hide | Not Applicable | The application does not contain any moving, blinking, scrolling, or auto-updating information by default. Since clients are responsible for uploading their own content, such as videos or other media, they may introduce elements that could potentially involve moving or auto-updating. In such cases, it's the clients responsibility to ensure that their content complies with accessibility guidelines. |
2.3.1 Three Flashes or Below Threshold | Not Applicable | The application does not currently contain any flashing content. Since clients are responsible for uploading their own content, such as videos or other media, they may introduce flashing elements. In such cases, it's the clients responsibility to ensure that their content complies with accessibility guidelines. |
2.4.1 Bypass Blocks | Not Applicable | The application does not currently provide a dedicated 'skip to main content' mechanism. However, there are minimal navigation elements (side menu, profile icon and logo) before reaching the main content. We are reviewing potential improvements in future updates and will further evaluate. |
2.4.2 Page Titled | Supports | The application provides page titles that describe the purpose of each page. Some page titles are created by our clients. We recommend clients ensure their titles are meaningful and relevant to the content of each page. |
2.4.3 Focus Order | Partially Supports | The application supports navigation through screen readers, allowing users to complete most form fields and interact with other focusable components. The application does not rely on a physical or digital keyboard for navigation. We are reviewing components and exploring ways to improve. |
2.4.4 Link Purpose (In Context) | Partially Supports | The application supports link text displayed in blue and underlined, ensuring users can visually distinguish links from other text, however the actual 'text' is created by clients. We recommend clients use descriptive text that clearly conveys the purpose of the link text. We are always looking at ways we can help clients create descriptive and accessible link text. |
2.5.1 Pointer Gestures | Not Applicable | This application does not implement complex pointer gestures. |
2.5.2 Pointer Cancellation | Not Applicable | This application does not implement complex pointer gestures requiring cancellation mechanisms. |
2.5.3 Label In Name | Partially Supports | This application generally provides accessible names for interactive elements that match their visible labels, enabling compatibility with assistive technologies. However, not all buttons and controls currently have appropriate aria-label or equivalent markup. We are reviewing our elements and taking account for which elements will need to be updated to ensure full compliance in the future. |
2.5.4 Motion Actuation | Not Applicable | This application does not implement motion actuation features. |
3.1.1 Language of Page | Supports | The application supports a default language. We do not support selection of languages at this time however we do implement internationalization for user-facing text, so that we are ready if it is needed. |
3.2.1 On Focus | Partially Supports | The application supports focus management primarily through assistive technologies such as screen readers, which provide appropriate feedback when interactive elements receive focus. Since our application does not rely on a physical or digital keyboard for navigation, focus indicators are not applicable in the traditional sense. We are committed to maintaining a predictable and stable user experience. |
3.2.2 On Input | Supports | The application does not trigger any unexpected context changes upon user input. |
3.3.1 Error Identification | Supports | The application supports error identification and descriptions for input errors, however we recognize there is always room for improvement in how these are communicated and look to feedback from our users. |
3.3.2 Labels or Instructions | Supports | The application provides labels for inputs to ensure clarity and guidance. We also provider helper text where applicable. |
4.1.1 Parsing | Supports | The application can be understood by assistive technologies. We believe our code is properly structured. |
4.1.2 Name, Role, Value | Supports | The application ensures that all user interface components have programmatically determined names, roles, and values, and that changes to their states are accessible to assistive technologies. We are always looking to improve our code base but believe we are compliant at this time. |
| WCAG Success Criteria | Conformance Level | Remarks and Explanations |
1.2.4 Captions (Live) | Not Applicable | Any video content within the application is uploaded by clients. They are responsible for ensuring live captions are provided. |
1.2.5 Audio Description (Prerecorded) | Not Applicable | Any audio content within the application is uploaded by clients. They are responsible for ensuring audio descriptions are provided. |
1.3.4 Orientation | Partially Supports | The application requires portrait orientation throughout. This restriction is due to the layout and functionality of specific features, such as the digital scorecard and GPS, where portrait orientation is essential for usability. Support for other orientations may be explored in future updates. |
1.3.5 Identify Input Purpose | Supports | The application, where applicable, uses standard HTML input types (e.g., email, phone number, etc.) to identify the purpose of the form fields. |
| 1.4.3 Contrast (Minimum) | Supports | The application uses high-contrast text. However, clients can customize parts of the application's colors (e.g., buttons, title header color), which may result in insufficient contrast. To assist clients, we provide a color contrast checker to inform them if their colors meet WCAG 4:5:1 contrast ratio for text. They are responsible for ensuring the colors they 'save' are compliant. |
1.4.4 Resize Text | Does Not Support | The application supports pinch-to-zoom on iOS but not on Android. We are looking into moving towards using relative font size, so that our content takes into consideration user preferences. Our hope is to be able to implement resize text end of 2025 or early 2026. |
1.4.5 Images of Text | Partially Supports | The application uses real text over images for certain features (e.g., Rewards). However, clients may upload promotional images or banners that contain text, which are not programmatically accessible. We are working on ensuring alt text is available for all images clients upload so they are able to provide descriptions for assistive technologies. |
1.4.10 Reflow | Partially Supports | The application supports layouts that generally reflow well on different screen sizes (iPhone to iPad), but certain components (e.g., GPS, Scorecard) may require horizontal scrolling. We will continue to evaluate reflow across the application. |
1.4.11 Non-text Contrast | Supports | The application uses high-contrast colors for non-text elements by default. However, clients can customize parts of the application's color (e.g., buttons, title header color), which may result in insufficient contrast. To assist clients, we provide a color contrast checker that alerts them if their colors do not meet the WCGA 4:5:1 contrast ratio. They are responsible for ensuring the colors they 'save' are compliant. |
1.4.12 Text Spacing | Does Not Support | The application does not support spacing overrides via device accessibility settings; however we are reviewing the ability to allow for additional spacing accommodations. |
1.4.13 Content on Hover or Focus | Not Applicable | The application allows for tapping to access custom tooltips, where applicable. |
| 2.4.5 Multiple Ways | Supports | The application is not a traditional website so we do not support sitemaps or search functionality however the application supports multiple navigation options - home screen buttons, side menu and new footer menu coming in 2025. We also provide multiple methods to navigate horizontal content: swipe on touch devices or use navigational buttons. |
2.4.6 Headings and Labels | Supports | The application uses clear and descriptive headings and labels to ensure users can easily understand the content or purpose of each section. Clients are able to create headings on some pages and are responsible for ensuring they are easily understood. |
2.4.7 Focus Visible | Partially Supports | The application does not rely on a physical or digital keyboard, however, we ensure focus indicators are visible when using assistive technologies like VoiceOver and TalkBack. |
2.4.11 Focus Not Obscured (Minimum) | Supports | This application exposes a keyboard interface during form interactions. When a form field receives focus, they remain at least partially visible and are not completely obscured by other UI elements or the on-screen keyboard. |
2.5.7 Dragging Movements | Not Applicable | This application does not utilize drag-and-drop functionality. Instead, users can interact with the app through swipe gestures. |
2.5.8 Target Size | Partially Supports | This application ensures that most interactive elements, such as buttons and links, meet the minimum target size of 44x44 CSS pixels. However, there are some areas where the target size may fall below the recommended minimum. We are currently reviewing and looking to improve those areas at a future time. |
| 3.1.2 Language of Parts | Not Applicable | The application supports a default language and implements internationalization for user-facing text. While multiple language selections are not support at this time, the system is prepared for future language needs. |
3.2.3 Consistent Navigation | Support | The application supports a side menu and future footer menu. Those menus will maintain consistent order across the application. |
| 3.2.4 Consistent Identification | Support | The application ensures consistent identification of components with the same functionality across all pages. |
3.3.3 Error Suggestion | Partially Supports | The application provides error messages to inform users when input is incorrect, however we do not currently provide suggestions and is something we will consider in the future. |
3.3.4 Error Prevention (Legal, Financial, Data) | Not Applicable | The application does not handle legal or financial transactions. We allow users the ability to purchase and manage memberships. They can also request to delete their data at any time but we do not engage in a process that would require error prevention. |
3.3.8 Accessible Authentication (Miniumum) | Reviewing | |
4.1.3 Status Messages | Reviewing |
Perfomance Criteria | Conformance Level | Remarks and Explanations |
Blind / Screen Reader Users | Partially Supports | The application is accessible and navigable with screen reader technology, utilizing alt text, proper labeling, error identification, and semantic HTML structure where applicable. While the application does not support a physical or digital keyboard for navigation, keyboard functionality is enabled for form inputs. We have tested the application using VoiceOver and TalkBack assisted technologies. |
Low Vision Users | Partially Supports | The application does not fully support text size adjustments, but does provide some information in icon-based indicators, where applicable to convey information without relying on color. Success messages are displayed without the need for color cues. Error messages are displayed next to input fields to assist users in identifying issues without the need for color cues and most images use alt text to enhance accessibility for low vision users. |
Hearing Loss Users | Not Applicable | The clients are responsible for audio or video content and ensuring that any audio or video content uploaded or used within the application complies with accessibility guidelines for hearing loss users, including the provisions of captions, transcripts and visual alerts as needed. |
Limited Mobility (Keyboard Users) | Not Applicable | The application does not provide a physical or digital keyboard for navigation. However, users can interact with the app using assistive technologies such as screen readers or voice commands. We are focused on ensuring the application is navigable through these technologies to accomodate users with limited mobility. |