WCAG Break Down
TheA breakdownreview of how the CrowdComms Front End application scoresmeasured against the Web Content Accessibility 2.1 2 requirements.
|
||
WCAG Requirements |
Current CC Platform build complaint with standards |
Notes |
1.Perceivable | Partial | |
1.1Text Alternatives | Partial | Braille not supported, as each app is custom built we cant confirm the FE |
"Simpler language" cant be confirmed as app is custom built so the language complexity used cant be defined by CrowdComms but we have the ability to select multiple different languages if the app is required to support them. |
||
1.1.1Non-text Content | Yes | |
1. |
No | As each app is custom built we cant confirm the FE media will also be replicated with alternative |
1.2. |
No | As each app is custom built we cant confirm the FE media will also be replicated with alternative Alternative for time based media could include transcripts added as documents into applications for example but this is upon the requirements of each unique client. |
1.2. |
As each app is custom built we cant confirm the FE media will contain captions supports sign language. Video functionality allows for Closed Captions to be generated and stored at the time of video creation but only if the designed requirements of the client specify this functionality is enabled. |
|
1.2.3Audio Description or Media Alternative ( |
No | As each app is custom built we cant confirm the FE media will have audio description. |
1.2.4Captions (Live) | As each app is custom built we cant confirm the FE media will Video functionality allows for Closed Captions to be generated and stored at the time of video creation but only if the designed requirements of the client specify this functionality is enabled. |
|
1.2.5Audio Description ( |
No | As each app is custom built we cant confirm the FE media will have audio description. |
1.2. |
No | As each app is custom built we cant confirm the FE media will have sign language. |
1.2. |
No | As each app is custom built we cant confirm the FE media will have audio description. |
1.2. |
No | As each app is custom built we cant confirm the FE media will have audio description or sign language. |
1.2. |
No | As each app is custom built we cant confirm the FE media will have audio description or sign language. |
1. |
Yes | |
1.3. |
No | As each app is custom built we cant ensure App |
1.3. |
No | As each app is custom built we cant ensure data |
1.3. |
No | As each app is custom built we cant ensure content shape or location will allow all users to understand the data being presented. |
1.3. |
Yes | |
1.3. |
Partial | All user input fields on a standard CC product are clear in what the content should be and have alternative text available for screen readers. Data input by users such as in a Live Poll can be extracted for data analysis. |
1.3. |
No | As each app is custom built we cant confirm content or symbols will be appropriate for all users to understand. Basic product layout is the same in most cases but nothing prevents clients from changing layouts, moving content, hiding content or adjusting it's |
1. |
Yes | |
1.4. |
Yes | |
1.4. |
Yes | |
1.4. |
No | As each app is custom built we cant confirm that text or images of text have a contract ratio of 4:5:1. |
1.4. |
Yes | FE is responsive, adjusting to reflect screen size so if a user zooms into an app the screen adjusts to correctly display the content in its adjusted size. |
1.4. |
No | As each app is custom built we cant ensure text font, colour, spacing, blank spaces, paragraphs or size is appropriate. |
1.4. |
No | As each app is custom built we cant confirm that text or images of text have a |
1.4. |
No | As each app is custom built we cant confirm the FE media will not have background audio. The ability to filter out audio background is not a supported functionality. |
1.4. |
Partial | Foreground and background colours are selected as a design feature but not |
1.4. |
No | As each app is custom built we cant |
1.4. |
As the FE is responsive the CSS height and width is adjusts to reflect screen size changes without any limits of minimum/maximum pixel size. Content is |
|
1.4. |
||
1.4. |
No | As each app is custom built we cant ensure |
1.4. |
Partial | Most selectable content on a standard app version has a hoover alternative state. |
2. Operable | Partial | |
2. |
Yes | |
2.1. |
Yes | |
2.1. |
Yes | |
2.1. |
Partial | Embedded content such as Video Library videos and filters cant be selected via a keyboard only. |
2.1. |
||
2. |
Yes | |
2.2. |
||
2.2. |
Yes | |
2.2. |
Yes | |
2.2. |
||
2.2. |
Connection dropping for external features such as VBO and Zoom calls will require re-authentication but are driven by 3rd party software. |
|
2.2. |
No | No warning is displayed before user logout |
2. |
No | As each app is custom built we cant ensure content will not contain flashing images or induce physical reactions. |
2.3. |
Yes | |
2.3. |
Yes | |
2.3. |
No | No functionality yet built around giving the users the option to prevent animation or integration including |
2. |
Partial | FE can be navigated via keyboard, mouse and on native touch screen devices. No instructions on |
2.4. |
The Navigation menu bar is |
|
2.4. |
All modules and user menu options have a title within the head section but Documents and lists that can populate the page are custom built so we cant ensure titles of such content will be provided. |
|
2.4. |
Yes | |
2.4. |
No | As each app is custom built we cant ensure all links are in context and named |
2.4. |
No | As each app is custom built we cant ensure all pages are linked to each other directly and the requirement is not |
2.4. |
Yes | |
2.4. |
Yes | |
2.4. |
Partial | FE supports the use of the back button in the app and most builds of the application leave the user navigation bar present which can be selected from any module however as each app is custom built we cant ensure all apps built follow this model. |
2.4. |
||
2.4. |
As each app is custom built we cant ensure all pages have sub headers where |
|
2. |
Yes | |
2.5. |
Yes | |
2.5. |
||
2.5. |
No | As each app is custom built we cant ensure labels are appropriate for their content. |
2.5. |
Not applicable. There is no functionality impacted by device motion other than on tablets and mobile devices when the screen size corresponds to the portrait or landscape state of the device. | |
2.5. |
No | As each app is custom built we cant ensure target size is a minimum of 44 CSS pixels. |
2.5. |
Yes | |
2.5.7 Dragging Movements | Yes | |
2.5.8 Target Size (Minimum) | No | As each app is custom built we cant ensure all target input sizes are of a minimum 24 pixels or have applied selection alternatives present. |
3. Understandable | Partial | |
3. |
Yes | |
3.1. |
Yes | |
3.1. |
Yes | |
3.1. |
No | As each app is custom built we cant ensure what words are used or if there is any dictionary or jargon buster present on the FE app. |
3.1. |
No | As each app is custom built we cant ensure what abbreviations are used or if there is any dictionary or jargon buster present on the FE app. |
3.1. |
||
As each app is custom built we cant ensure all |
||
3.1.6 Pronunciation | No | As each app is custom built we cant ensure a mechanism is put to provide contexts to ambiguous words. |
3. |
Yes | |
3.2.1 On Focus | Yes | |
3.2.2 On Input | Yes | |
3.2.3 Consistent Navigation | Yes | |
3.2.4 Consistent Identification | Yes | |
3.2.5 Change on Request | Yes | |
3.2.6 Consistent Help | No | As each app is custom built we cant ensure any help information or contact details is presented in the same order on all pages. |
3.3 Input Assistance | Yes | All standard input fields within the app are clear about what data is expected to be held there and which input fields are mandatory. |
3.3. |
Yes | |
3.3.2 Labels or Instructions | No | As each app is custom built we cant ensure labels or instructions are present for all user inputs. |
3.3. |
Partial | As each app is custom built we cant ensure all errors present suggestions but in the standard build of the application all login failures, failed save attempts and user profile update failures indicate a reason for the error. |
3.3. |
No | As each app is custom built we cant ensure user submissions are revisable, checked or reversible. |
3.3. |
||
3.3.6 Error Prevention (All) | Yes | Data input by users can be reversible except in specific defined individual instances such as voting. Input fields such as User name etc. can be edited multiple times. Data entered in mandatory fields is checked |
4. Robust | Yes | |
4. |
Yes | |
4.1. |
Yes | |
4.1. |
Yes | |
4.1. |
||
5. Conformance | No | As each app is custom built we cant ensure conformance standards are met or that a user cant be directed from the FE app to a none conformance location. |
5. |
No | As each app is custom built we cant ensure |
5. |
No | As each app is custom built we cant ensure confirmation standards are maintained. |
5.2. |
No | As each app is custom built we cant ensure confirmation standards are maintained. |
5.2. |
Yes | |
5.2. |
Yes | |
5.2. |
Yes | |
5.2. |
Yes | |
5. |
No | No functionality to support conformance claims. |
5.3. |
No | No functionality to support conformance claims. |
5.3. |
No | No functionality to support conformance claims. |
5. |
No | As each app is custom built we cant ensure a statement of conformance with third party content is displayed. |
5. |
No | As each app is custom built we cant ensure a statement of conformance with |