Menu Toggle
More
    Close

    New mobile app Statement

    Statement: Platform accessibility features MUST be optimally used and behave as intended. App designers must follow platform-specific design guidelines to ensure accessibility.

    Benefits: Mobile platforms offer various accessibility settings such as contrast, color inversion, large text, grayscale, and mono audio.These settings allow users to customize their device to meet their specific needs, such as users with visual or hearing impairments. App developers need to review and ensure that their apps behave correctly with each accessibility feature. Providing accessibility settings benefits users with disabilities by improving the accessibility of the app, and enhances usability for all users in certain scenarios.

    Department Action: Ensure designers and developers are aware of platform accessibility settings and how they can be incorporated into the app and Incorporate accessibility testing into the app development process to ensure compliance with platform-specific guidelines

    Developer Action: Follow platform-specific design guidelines to ensure the app behaves correctly when accessibility settings are enabled and test the app with accessibility settings enabled to ensure compliance and functionality

    Reference: WCAG 2.1 – 1.3.3, 1.4.1 , 1.4.3 , 1.4.4, 1.4.5, 1.4.6 , 1.4.8

    Evaluator Action:

    • Verify that the app follows platform accessibility settings and guidelines
    • Test the app with accessibility settings enabled to ensure functionality and compliance
    • Provide recommendations for improving accessibility and usability for users with disabilities

    Statement: UI elements must have accessible labels for images, buttons, and controls. Labels embedded in images must be avoided, and labels must be precise, clear, and updated timely when the functionality of the UI element changes. Role and state information must not be provided in the label, and label strings must be localized for users in different languages.

    Benefits: Providing accessible labels for all UI elements ensures that users with disabilities can easily navigate and interact with the app using assistive technologies such as VoiceOver or TalkBack. Clear and precise labels also benefit all users, making it easier for them to understand the purpose of each UI element.

    Department Action: The department should ensure that all UI elements have proper and accessible labels. They should also establish guidelines for labelling UI elements, including using action verbs, The department should also ensure that label strings are localized for users in different languages.

    Developer Action: Developers should follow the department’s guidelines for labelling UI elements. They should ensure that each UI element has a precise and clear label that describes its purpose. Developers should also update labels when functionality changes, and not include role or state information in the label. They should ensure that label strings are localized for users in different languages.

    Reference:

    Evaluator Action:

    • Evaluators should ensure that all UI elements have accessible labels and that the labels are clear and precise. Evaluators should also check that labels are updated when functionality changes and that role and state information is not included in the label.

    Statement: The role for a UI element must be available programmatically so that assistive technology can report this either through speech or Braille. Platform-specific roles or traits must be used for standard UI elements, and platform accessibility API must be used for custom UI elements to report the role information.

    Benefits: Provides accessibility for blind or visually impaired users by allowing them to interact with UI elements using assistive technology. Ensures compliance with accessibility guidelines and standards.

    Department Action:

    Developer Action: Use platform specific roles or traits for standard UI elements. Use platform accessibility API to report role information for custom UI elements. Test the accessibility of UI elements with assistive technology to ensure that they are programmatically identifiable.

    Reference: WCAG 2.2 – 4.1.2

    Evaluator Action:

    • Check that UI elements have programmatically available roles.
    • Use assistive technology to test the accessibility of UI elements.

    Statement: Hints MUST be provided for all active UI control elements. Hints are only required for UI controls that allow users some interaction, and in case of custom UI controls, hints must also report the screen reader gestures that users could perform to interact with the control. Standard UI controls have hints supplied by the APIs, but those hints might have to be changed depending on the usage.

    Benefits: Hints improve the user experience by providing additional context and guidance for interacting with UI controls. Hints help users with disabilities, especially those using assistive technologies, to understand the purpose and functionality of the UI control and how to interact with it.

    Department Action: Departments must make sure the hints are properly localized.

    Developer Action: Developers should ensure that hints are provided for all active UI control elements that allow user interaction and these should be concise, clear and localized for the target audience. For custom UI controls, developers should provide information about screen reader gestures that users can perform to interact with the control.

    Reference: WCAG 2.2 -3.3.2:

    Evaluator Action:

    • Evaluators should check if hints are provided for all active UI controls that allow user interaction.
    • Evaluators should also check if hints are concise, clear, and properly localized for the target audience.
    • For custom UI controls, evaluators should check if screen reader gestures are included in the hints.

    Statement: Assistive technologies must identify the current state of a UI control in addition to its role. This information must also be reported as soon as it is changed. The changes of state of UI controls must be dynamically updated and accurately available to the assistive technologies.

    Benefits: Provides information to assistive technologies about the current state of UI controls.Allows users with disabilities to interact with the UI control and understand its current state, even if they cannot see it visually. Improves the overall accessibility of the application, making it more inclusive for all users.

    Department Action:

    Developer Action: Developers must use platform-specific accessibility APIs to identify the current state of UI controls. They must ensure that changes in the state of UI controls are dynamically updated and accurately reported to assistive technologies. For example, the state of a checkbox (checked/unchecked), a selected or unselected tab, or a pressed or unpressed push button must be notified. They must test the application with assistive technologies to ensure that the state information is being correctly identified and reported.

    Reference: (WCAG) 2.1 – 4.1.3.

    Evaluator Action:

    • Verify that the application provides accurate and timely state information for all UI controls, using platform-specific accessibility APIs.
    • Test the application with assistive technologies to ensure that the state information is correctly identified and reported to users.

    Statement: “Related UI elements, such as the book title and author name for a book, MUST be grouped together so that assistive technologies can present them as a single UI element, reducing the gestures for interaction. The following points are important for grouping related elements:

    • A group must have only one actionable UI control.
    • Updating UI controls, such as progress bars, must not be grouped with any other control, as users need only the updated information.”

    Benefits: Grouping related UI elements together can make it easier and more efficient for users with disabilities to interact with them. By presenting them as a single UI element, it reduces the number of gestures required for interaction and increases the touch target, making it easier for users with low vision, motor difficulties, or big fingers to interact with them.

    Department Action:

    Developer Action: Developers should implement grouping of related UI elements as per the design specification. They should also ensure that any actionable UI control is included in only one group and that progress bars are not grouped with any other control.

    Reference: WCAG 2.1- 3.3.7.

    Evaluator Action: Evaluators should check that related UI elements are appropriately grouped and that the grouping does not affect the usability of the interface negatively. They should also ensure that any actionable UI control is included in only one group and that progress bars are not grouped with any other control.

    Statement: UI should be clean and simple. Vertical and horizontal scrolling should be avoided. A non-interactive space of at least 1 point for iOS or 1 DP for android must be provided between actionable UI elements.

    Benefits: Clean and simple UI makes it easier for users to understand and interact with the app. Avoiding vertical and horizontal scrolling allows users with low vision to zoom and see the content more clearly and interact with the controls with ease. Providing non-interactive space between actionable UI elements helps to reduce the risk of accidental touches for users with motor difficulties or big fingers.

    Department Action:

    Developer Action: Developers should avoid vertical and horizontal scrolling where possible. They should also provide non-interactive space between actionable UI elements to make it easier for users with low vision, motor difficulties, or big fingers to interact with the app.

    Reference: UI design guidelines provided by the platform ( Android or iOS)

    Evaluator Action:

    Statement: Many users find it difficult to interact with small screen elements. It could be due to big or unsteady fingers or motor or visual difficulties. So, the touch targets MUST be at least 9×9 mm regardless of screen size.

    Benefits: Improved usability for users with big or unsteady fingers, motor difficulties, or visual impairments.Reduced likelihood of accidental taps or selecting the wrong UI element.

    Department Action:

    Developer Action: Developers should implement touch targets for UI elements to be at least 9×9 mm. and if necessary, adjust the spacing between UI elements to ensure proper touch targets.

    Reference:

    Evaluator Action:

    • Verify that all UI elements have touch targets of at least 9×9 mm.
    • Verify that there is proper spacing between UI elements to allow for proper touch targets.

    Statement: When a button is used to bring up other UI elements such as dropdowns, it MUST receive focus to notify blind and low vision users of the UI change.

    Benefits: Helps blind and low vision users to recognize changes in the UI and interact with it more efficiently. Improves the user experience for all users, including new and inexperienced ones. Reduces the risk of errors and timeouts due to difficulties in identifying the active UI element. Without proper focus, users may have to make multiple attempts to find the new element or risk a timeout.

    Department Action:

    Developer Action: Ensure that activation buttons and related UI elements are properly linked and that the focus is set to the active UI control. Test the interactions to ensure that the focus is set as intended

    Reference: WCAG 2.1 – 2.4.3

    Evaluator Action:

    • Check that activation buttons and related UI elements are properly linked and that the focus is set to the active UI control when activated
    • Test the interactions to ensure that the focus is set as intended, and that blind and low vision users can identify changes in the UI and interact with it efficiently.

    Statement: When content is navigated using screen reader gestures, it MUST form a meaningful sequence. The controls on the mobile screens and the interaction produced need to be logical to ensure a seamless user experience for screen reader mobile users.

    Benefits: Screen reader mobile users can easily navigate and interact with the content and UI controls.Content will form a meaningful sequence, making it easier for users to understand and follow.

    Department Action:

    Developer Action: Developers should make sure that the content and UI controls are structured in a logical and meaningful way to support screen reader navigation.Developers should test the mobile application using screen reader gestures to ensure that the content sequence is logical and meaningful.

    Reference: WCAG 2.1 -1.3.1

    Evaluator Action: The evaluator should check that the content sequence is logical and meaningful when using screen reader gestures to navigate and interact with the content.

    Statement: App must resize UI elements according to device text size settings for users with low vision.

    Benefits: This guideline ensures that users with low vision are able to increase the size of the UI elements to a comfortable level, allowing them to use the app with ease.

    Department Action:

    Developer Action: Ensure that the app’s UI elements are resizable according to the device settings for text size. Test the app with various text size settings to ensure that the UI elements are scaling properly and remain usable. Ensure that the UI elements remain usable and do not overlap or become distorted when resized.

    Reference:

    Evaluator Action:

    • Test the app with various text size settings to ensure that the UI elements are scaling properly and remain usable.

    Statement: Color contrast ratio between foreground and background must be at least up to 18 point font and background must be at least 4.5:1

    Benefits: Users with low vision or in poor lighting conditions can easily differentiate foreground elements from the background, making the UI more accessible and usable.

    Department Action:

    Developer Action: Developers should implement the color contrast as specified in the guideline. Developers should also ensure that dynamic UI elements such as pop-ups and error messages maintain the same color contrast ratio as the rest of the UI.

    Reference: WCAG 2.1 – 1.4.3.

    Evaluator Action:

    • The evaluator should test the UI for color contrast ratio and report any violations to the design and development departments for correction.
    • The evaluator should also ensure that the color contrast ratio is maintained across all UI elements and not just limited to text.

    Statement: App designers must ensure accessibility of both onscreen and hardware keyboards with assistive tech.

    Benefits: Ensuring keyboard accessibility benefits users with disabilities as well as enhances the comfort of other users.

    Department Action:

    Developer Action: Developers should avoid automatically changing focus while the user is entering data and should only change focus when the user activates a UI element for confirming an action. They should also ensure that the appropriate on-screen keyboard is invoked based on the type of field or data that needs to be provided. Finally, they should test the app’s compatibility with hardware keyboards.

    Reference: WCAG 2.1 Guideline 2.1.1

    Evaluator Action: Evaluators should test the app’s accessibility with both onscreen and hardware keyboards and ensure that the appropriate keyboard is invoked for different types of data input. They should also verify that the app does not automatically change focus while the user is entering data.

    Statement: Gestures requiring 3+ fingers to interact with UI elements must be avoided or provide an alternative/custom gesture for users with limited finger use.

    Benefits: Users with physical disabilities who have difficulty using multiple fingers or one hand can still access the application. Providing alternative methods for performing complex gestures can increase the usability and accessibility of the application.

    Department Action:

    Developer Action: Developers must Avoid using complex gestures that require three or more fingers to interact with UI elements. In case complex gestures are used, developers must provide an alternative to perform the same action or allow the user to create a custom gesture, such as providing an additional setting to customise gestures as per user requirements.

    Reference: WCAG 2.1 – 2.5.1

    Evaluator Action:

    • The evaluator should test the application’s gesture-based interactions with assistive technology to ensure that they are accessible to users with disabilities.
    • The evaluator should check that alternative methods are provided for performing complex gestures, such as customisation or alternative gestures.

    Statement: Avoid session timeouts and provide users an option to extend time limits before timeouts occur. Focus should be properly set on the time extension element.

    Benefits: Provides a more inclusive and accessible user experience for users who require extra time to complete actions.

    Department Action:

    Developer Action: Implement session timeout functionality in a way that allows for user time extensions. Ensure that the time extension element is properly labeled and that its focus is set correctly.Test session timeout functionality with assistive technologies such as screen readers and magnifiers.

    Reference: WCAG 2.1 – 2.2.1

    Evaluator Action:

    • Check that the application does not have session timeouts, or that there is an option for users to extend the time limit.
    • Check that the time extension element is properly labeled and that its focus is set correctly.
    • Verify that the session timeout functionality has been tested with assistive technologies such as screen readers and magnifiers.

    Statement: Captions must be provided for all audio content and subtitles/transcripts must be provided for all video content accompanied by audio to assist users with hearing difficulties or those who find it difficult to understand the audio.

    Benefits: Captions and transcripts make audio and video content accessible to users who have hearing difficulties or find the language in the audio difficult to understand. It also enhances the user experience for all users by providing an additional way to consume the content.

    Department Action: The department must ensure that captions or transcripts are created for all audio and video.

    Developer Action: The developers should implement the necessary features to enable captions or transcripts for audio and video content. They should also test the functionality to ensure that the captions or transcripts are properly synced with the audio or video.

    Reference:

    • WCAG 2.1 – 1.2.2
    • WCAG 2.1 – 1.2.3

    Evaluator Action: Evaluators should check that captions and transcripts accurately convey the spoken content and are synchronized with the audio.

    Statement: Provide audio descriptions for video content crucial for blind users to understand the content. Not necessary to provide audio for non-essential video content.

    Benefits: Allows blind users to have access to important visual information in video content.

    Department Action: The department should ensure that audio descriptions for video content are created. Developers should also distinguish between decorative/non-essential video content and crucial video content that requires audio description.

    Developer Action: Developers should provide a provision to publish audio description with video content.

    Reference: WCAG 2.1 – 1.2.5

    Evaluator Action:

    • The evaluator should test the application to ensure that audio descriptions are provided for video content.

    Statement: To ensure the safety of users who are prone to seizures, it MUST be required that no content should flash more than 3 times per second.

    Benefits: This requirement ensures that users who are susceptible to seizures due to flashing content are not put at risk. By limiting the flashing content, the application becomes more accessible and safe for a larger group of users.

    Department Action:

    Developer Action: Developers need to test and monitor all content and animations within the application to ensure that nothing flashes more than three times in one second. They need to ensure that any content or animations within the application are designed in a way that does not exceed the flashing limit. If content does exceed the limit, it needs to be modified or removed.

    Reference: WCAG 2.1 guideline 2.3.1: Three Flashes or Below Threshold

    Evaluator Action: They may use automated tools or manual testing methods to check for compliance with this requirement.

    Statement: Notifications should be audible and readable by screen readers. Use OS alerts or clear and precise custom-made notifications.

    Benefits: Notifications help users stay informed and guide them through their interactions with the application.Audible notifications and notifications that can be read by screen readers make the application more accessible to users with disabilities.

    Department Action:

    Developer Action: Developers should use operating system alerts or inline messages to ensure that the notifications are easily understood by users. Custom notifications should be designed to be clear, concise, and understandable. Notifications should be designed to be audible and accessible to screen readers.

    Reference: WCAG 2.1, specifically success criterion 4.1.3

    Evaluator Action:

    • The evaluator should check that the notifications are clear, concise, and understandable.
    • The evaluator should check that the notifications are audible and accessible to screen readers.
    • The evaluator should test the notifications to ensure that they are effective in informing and guiding users.

    Statement: Apps MUST be tested thoroughly to ensure they look good on different screen sizes and run on popular versions of the target platform before being uploaded to the app store.

    Benefits: Testing apps before release helps ensure that users have a positive experience with the app, resulting in higher user engagement and retention.

    Department Action:

    Developer Action: Developers should test the app on different screen sizes and popular versions of the target platform to ensure it runs smoothly and looks good on all devices. Any issues identified during testing should be fixed before release.

    Reference:

    Evaluator Action: The evaluator should perform rigorous testing on different devices with different screen sizes and popular versions of the target platform to ensure compliance with guidelines and identify any issues that need to be fixed before release.

    Statement: The app MUST be promoted in the app stores to increase awareness and visibility to potential users.

    Benefits: Promoting the app in the app stores can increase app downloads, improve app visibility, and raise brand awareness.

    Department Action: The marketing department should create a promotional plan that includes developing a clear and concise messaging strategy, identifying target audiences, and choosing the right promotion channels. The promotional plan should comply with the respective platform’s promotional guidelines.

    Developer Action: Developers should work closely with the marketing department to ensure that the app is ready for promotion. This may include optimizing the app store listing, updating the app’s visuals, and ensuring that the app has a smooth user experience.

    Reference:

    Evaluator Action: The evaluator will review the app store listing and promotional plan to ensure that it complies with the respective platform’s promotional guidelines and best practices.

    Statement: User feedback and reviews on platform-specific stores MUST be constantly monitored to provide an important source of suggestions and improvements for the app.

    Benefits: By monitoring user feedback and reviews, developers can gain valuable insights into the app’s performance, identify issues and bugs, and collect suggestions for improvements. This helps in enhancing the app’s quality and user experience, which can lead to increased user engagement and loyalty.

    Department Action: Departments should assign a team or an individual to regularly monitor user feedback and reviews on the app’s platform-specific stores. They should respond to user feedback and reviews promptly and professionally, thanking users for positive feedback and addressing any issues or concerns raised in negative feedback. Department should also use user feedback and reviews as a source of inspiration for future app updates and improvements.

    Developer Action: Developers should make it easy for users to provide feedback and leave reviews on the app’s platform-specific store page. They should analyze the feedback and reviews received and take appropriate action, such as fixing issues, implementing suggestions.

    Reference:

    Evaluator Action: The evaluator will check whether the app developer has assigned a team or an individual to monitor user feedback and reviews on the platform-specific store page, and whether appropriate action has been taken in response to the feedback and reviews received.

    Statement: Mobile API Hosting:

    • Security audited APIs MUST be hosted in highly secure data centers equipped with firewalls and other security features.
    • Hosting service providers MUST provide 24X7 access to APIs and backend databases.
    • Appropriate disaster recovery sites MUST be configured at different geographical locations to avoid disruption of service in case of natural or manmade disasters.
    • API hosting service providers must also provide technical support and help to the owner of the application.
    • Adequate security measures must be built into the API to detect and discourage unauthorized use of the APIs.

    Benefits: This ensures that the data accessed by the API is kept secure and protected from unauthorised access or cyber attacks. This also ensures uninterrupted service and quick recovery from any disasters or disruptions.

    Department Action: The department must ensure that the hosting service provider adheres to the security standards and provides disaster recovery sites at different geographical locations. They should also ensure that technical support and help is provided to the application owner.

    Developer Action: Developers must build adequate security measures into the API to detect and discourage unauthorised use of the APIs.

    Reference:

    Evaluator Action: The evaluator will test the API manually and/or using automated tools to check compliance with the security standards.

    Statement: When creating a privacy policy for a mobile application, it must clearly state the purpose of collecting user information and which mobile resources the app has access to.

    Benefits: Providing clear and concise information about data collection and access to mobile resources builds trust with users and can help prevent potential legal issues.

    Department Action: The department responsible for creating the privacy policy should clearly outline the purpose of data collection and access to mobile resources. The policy should also include information about user-provided data such as registration details, system usage, and any automatically collected information such as device type and location. Data retention policies and security measures to protect user information should be clearly stated. The policy should also outline the process for disclosing user information as required by law or to protect the rights and safety of others. Regular review and updates to the policy should be conducted, and contact information for privacy-related inquiries should be provided.

    Developer Action: Developers must ensure that the privacy policy accurately reflects the purpose of data collection and access to mobile resources. They must also provide the user with clear and concise information about how their data is being collected and used. Developers should ensure that the privacy policy is easily accessible within the application and that users are prompted to read and accept the policy before using the app.

    Reference:

    Evaluator Action: The evaluator will review the privacy policy to ensure that it accurately reflects the purpose of data collection and access to mobile resources. The evaluator will also ensure that the policy provides clear and concise information about how user data is collected and used, and that it is easily accessible within the application.

    Statement: Terms and conditions for the app must be clear, concise, and contain necessary information regarding ownership details, usage policy of content, and legal aspects to guide both the owner and the user of the app.

    Benefits: Clear and concise terms and conditions enable both the owner and users of the app to understand their rights and responsibilities. They help avoid disputes and conflicts, and protect the owner’s intellectual property rights.

    Department Action: The department responsible for creating the app should create terms and conditions that accurately reflect the usage policy and legal aspects of the app. The terms and conditions should be reviewed and updated regularly to ensure they are up to date and accurate.

    Developer Action: Developers should ensure that the terms and conditions are displayed prominently in the app and are easily accessible to users. They should also ensure that the terms and conditions are incorporated into the app’s design and functionality, so that users are required to agree to them before using the app.

    Reference:

    Evaluator Action: The evaluator should review the terms and conditions to ensure that they are clear, concise, and contain the necessary information. The evaluator should also ensure that the terms and conditions comply with applicable laws and regulations.

    Statement: Touch down events should be avoided to perform any action, as it can interfere with assistive technologies for mobiles like Voiceover or Talkback gestures. However, software that is visual in nature, like drawing apps, may use touch down events.

    Benefits: By avoiding the use of touch down events for actions, mobile users with disabilities can access and use the app without interference from assistive technologies. This improves accessibility and usability for a wider range of users.

    Department Action:

    Developer Action: Developers should avoid using touch down events to perform any action and instead use other touch gestures that do not interfere with assistive technologies. They should also ensure that the app meets accessibility requirements and can be used by a wider range of users.

    Reference: WCAG 2.1 – 2.1.1 & 2.1.2

    Evaluator Action: Evaluators should check the app to ensure that touch down events are not used for actions, except for software that is visual in nature like drawing apps. They should also verify that the app meets accessibility requirements and can be used by a wider range of users.

    Statement: Each screen MUST have a clear and distinguishable title marked as heading level 1, to help users understand the primary purpose of the screen and distinguish it from labels for other controls.

    Benefits: Users with disabilities, including those who use assistive technologies, can easily understand the purpose of each screen, improving their ability to navigate and interact with the content.

    Department Action: When designing and developing digital content departments must ensure that each screen has a clear and descriptive title marked up as a heading level 1.

    Developer Action: Test the content to ensure that the title is properly marked up and distinguishable from other elements.

    Reference: WCAG 2.0-2.4.10

    Evaluator Action: When evaluating digital content for accessibility, verify that each screen has a clear and descriptive title marked up as a heading level 1. Test the content to ensure that the title is properly marked up and distinguishable from other elements.

    Statement: Each subsection in a screen MUST have a clear title with a heading level lower than the main title, provided that the technology for the device allows it.

    Benefits: Providing clear and distinguishable titles for subsections on a screen enables users to understand the content and navigate the interface efficiently. Without a proper title, users may find it difficult to understand the primary purpose of the subsection. Failure to mark the subsection as a heading can cause confusion, as users may mistake it for a label for another control.

    Department Action: The design and development department should ensure that each subsection in a screen has a clear and distinguishable title with the appropriate heading level. They should also verify that the title identifies the primary purpose of the subsection.

    Developer Action: The developers should use appropriate markup to identify the titles of subsections with the correct heading level. They should also test the interface to ensure that each subsection title is clearly visible and distinguishable.

    Reference: WCAG 2.0-2.4.10

    Evaluator Action: The evaluator should check that the titles of subsections on the screen are clearly distinguishable and identify the primary purpose of the subsection. They should also ensure that the headings are marked up correctly with the appropriate heading level.

    Statement: Every screen must have an option to navigate back to the previous screen, except for top-level screens.

    Benefits: Helps users navigate through the content and complete tasks easily and efficiently.Without the back button, users often get stuck on a screen as they do not find a way to go back, and they have to close the app and reopen it to go to the screen of interest. Enhances the overall user experience and increases user satisfaction.

    Department Action:

    Developer Action: Developers should include a back button or alternative navigation method on every screen, except for top-level screens. They should also ensure that the back button works properly and is accessible via touch gestures. Additionally, they should test the functionality of the back button using assistive technology.

    Reference: WCAG 2.0-2.1.1 & 2.1.2

    Evaluator Action: Evaluators should test the app or website to ensure that every screen has a back button or alternative navigation method. They should also ensure that the back button works properly and can be accessed using touch gestures. They should also test the functionality of the back button using assistive technology.