MCAG is intended to be a document that reflects the conformance requirements of the W3C's Web Content Accessibility Guidelines (WCAG 2.2) but also refers to the unique differences and challenges of mobile technologies that are not adequately expressed in WCAG. The document results from cross-referencing WCAG 2.2 success criteria with the accessibility guidelines of the different platforms and other sources. MCAG was written into the template and structure of WCAG, and it preserves the four POUR. However, since its use is intended for development teams, its internal division relies more on Apple's Human Interface Guidelines and Android's Accessibility Principles. Accordingly, the guidelines' names, divisions, and success criteria are different. The differences are reflected mainly in wording and affiliation. However, any changes were made with reference and an affinity to WCAG and its content. MCAG does not pretend to replace WCAG but only provides a uniform interpretation of it for mobile technologies while preserving its conformance requirements.
The document in front of you is a first draft and an invitation to cooperation and community discussion on the need for clear and dedicated guidelines for mobile technologies that will meet the needs of users and regulatory requirements. See the GitHub repository
1. Perceivable
This principle focuses on making information available through various sensory channels such as sight, hearing, or touch, allowing users to access and process the content effectively.
Guideline 1.1. Essential Info
This guideline deals with users' ability to perceive essential information to understand the essence of UI elements, how they are used, and what pieces of data they represent. This information is particularly crucial for assistive technologies like screen readers that rely on the programmatic information (i.e., the code) to communicate UI to the user.
Success Criterion 1.1.1. Accessibility Enabled
Assistive technologies can reach, parse, and convey essential content and user-operable elements in the UI.
Test
Impact
Notes
Assistive technologies can reach and programmatically read all essential content, except when:
The content has is a nearby equivalent alternative that's accessible to assistive technologies.
Critical
Assistive technologies can reach and trigger every user-operable element, except when:
The element has a nearby equivalent alternative that's operable by assistive technologies.
Success Criterion 1.1.3. Interactive Elements Have Names
Elements that require unique identifiers and context, have an accessible name that can be programmatically read. Examples include, but are not limited to, buttons, links, form elements, and groups of content.
Test
Impact
Notes
All the interactive UI components must have an accessible name programmatically determined.
Critical
Accessible names are set only on their designated properties according to the element's type.
The current state of elements supporting multiple states, such as (but not limited to) checkboxes, radio buttons, and drop-down lists, can be programmatically determined.
Test
Impact
Notes
Element's state can be programmatically determined and read.
Range between Serious and CriticalSerious → Critical
The states of elements are set only by the properties designated for them according to the element type. (see also 3.2.4 Clean Names)
Moderate
If an element's state has a visual representation, it must match the programmatic state.
For elements that return or represent values, such as (but not limited to) checkboxes, radio buttons, and form input fields, their value can be determined and read programmatically.
Test
Impact
Notes
If an element is returning a value, it can be programmatically determined and read.
Range between Moderate and CriticalModerate → Critical
Returned values are set only by the properties designated for them according to the element type.
Range between Minor and SeriousMinor → Serious
If an element's value has a visual representation, it must match the programmatic value.
Success Criterion 1.1.6. Sensory Characteristics in Content or Instructions
When providing any information or instructions, descriptions do not use only sensory characteristics, such as specifying a physical location in the UI (e.g., The button on the top left corner) or referring to the color of an element or sound playing.
Test
Impact
Notes
All the content can be perceived and correctly parsed by people with one or more sensory impairments.
Critical
Instructions and explanations are not based on specifying elements' location, color, or shape.
This guideline and its success criteria deal with media files embedded in the application, from static media, such as images, icons, and infographics, to time-based media, such as video or audio, and synchronized media. Since the content of media files is usually consumed in a sensory manner, often visual or auditory, they require alternatives so users with auditory or visual impairments can perceive the content and its context.
All static media have a text alternative with the equivalent meaning and purpose, and that can be parsed and presented by assistive technologies, except when the media element is used only for visual formatting or decoration, or it is not visually presented. In these cases, it should be implemented so that assistive technology can ignore it.
Test
Impact
Notes
Static media that present essential content have a text alternative.
The content has is a nearby equivalent alternative that's accessible to assistive technologies.
Critical
Static media that is purely decorative, used only for visual formatting, or is invisible in the UI is ignored by assistive technologies.
If an element is a player of time-based media, it has a title that can be programmatically read and provides a descriptive identification of the media content.
Test
Impact
Notes
Audio and video players have a title that is programmatically read by assistive technologies.
Success Criterion 1.2.5. Synchronized Media Alternatives
Live and prerecorded synchronized media tracks have alternatives equivalent to the media's audio and video content, so users with auditory or visual impairments can perceive the entire content.
Test
Impact
Notes
Every synchronized media track, prerecorded or live must provide captions.
Critical
Every prerecorded synchronized media track, or live must provide audio descriptions.
Different from the '1.3 Adaptable' WCAG guideline, which deals with the requirements of content to be presented in a manner that can be perceived in various ways, such as with different user agents or assistive technologies in the MCAG, this guideline deals with the ability of users to perceive asynchronous events that arrive from the app such as live updates and alert messages.
Toast messages are implemented so assistive technologies announce their content, and they stay visible for enough time so that all users can fully perceive them.
Test
Impact
Notes
The content of toast elements is announced by assistive technologies without the focus shifting to them.
Critical
The font size of toast messages should be at the size of the rest of the application’s body text
Serious
Each toast message should stay visible for at least 5 seconds plus one extra second for every 120 words (rounding up).
This guideline deals with issues related to the perception, identification, and understanding of interface elements by the user on a visual level. Similar to its parallel WCAG guideline, the success criteria of the 'Distinguishable' guideline on MCAG deal with issues like color contrast, visual prominence of elements in the UI, and visual indications of elements' states. Unlike the WCAG guidelines, the success criteria in the MCAG do not include success criteria dealing with text size and audio control issues, which have been incorporated into other guidelines.
Success Criterion 1.4.1. Text Color Contrast
Visual text must have a sufficient contrast in color from its background to be readable.
Test
Impact
Notes
Texts sized 17 points or less should have a contrast of at least 4.5:1 from their background, except when:
The text is part of a logo or brand name.
The text is a label of a disabled control.
The text is meant solely for decorative purposes and contains no essential information.
Range between Minor and SeriousMinor → Serious
We should try thinking of a key to scale the impact by contrast threshold.
Texts sized 18 points or higher should have a contrast of at least 3:1 from their background, except when:
The text is part of a logo or brand name.
The text is a label of a disabled control.
The text is meant solely for decorative purposes and contains no essential information.
Range between Minor and SeriousMinor → Serious
We should try thinking of a key to scale the impact by contrast threshold.
Texts with 'bold' font weight, in any size, should have a contrast of at least 3:1 from their background, except when:
The text is part of a logo or brand name.
The text is a label of a disabled control.
The text is meant solely for decorative purposes and contains no essential information.
Range between Minor and SeriousMinor → Serious
We should try thinking of a key to scale the impact by contrast threshold.
Success Criterion 1.4.2. Essential Elements' Color Contrast
Elements whose shape or manner of appearance is meaningful in understanding or operating the UI have a color contrast from their background of at least 3:1
Test
Impact
Notes
UI elements that can receive user input, such as buttons, links, and form controls, have a contrast of at least 3:1 from their background except when:
The control is in a 'disabled' state
Serious
Icons and infographics that convey essential information have a contrast of at least 3:1 from their background, except when:
The graphic element is a part of a disabled control.
This principle deals with the functional ability of users to operate controls and elements and complete tasks with various user agents and input modalities without disturbances, regardless of the user's personal abilities or inabilities.
Guideline 2.1. Gestures and User-input
This guideline deals with providing alternatives to complex gestures and predictable actions, ensuring that users can perform actions irrespective of any sensory, motoric or cognitive limitations they might have.
Success Criterion 2.1.1. Touch Target Size
Controls and other interactive elements have a minimum approximate size of 7 to 9 millimeters. For instructions on how to convert millimeters units standard on mobile app development, see Formulas for Measurement Units Conversion
Test
Impact
Notes
User-operable elements have a minimum size of 7x7 millimeters, except when:
There is a nearby equivalent link or control that meets the minimum size requirements;
The target is in a sentence or block of text;
The element is a default user agent control and was not modified by the author;
Range between Minor and SeriousMinor → Serious
If the element's size is slightly smaller than required, the impact will be minor; however, the smaller the element, the greater the impact severity. A formula must be determined to calculate the levels of severity depending on the element's size and possibly other variables like spacing and proximity to other interactive elements.
Success Criterion 2.1.7. Visible label included in accessible names
For UI components that have both a visible text label and an accessible name that's meant for assistive technologies, the visible name must be included in the accessible name.
Test
Impact
Notes
If an element has both visible label and an accessible name, the visible label’s text is included in the accessible name.
Serious
The accessible name text starts with the text of the visible label.
This guideline addresses the ability of users to consume and operate applications' content using external assistive technologies connected to their devices.
Smartphones are designed with various accessibility features to accommodate users with diverse needs, and they often support connectivity with external assistive technology devices. Some external assistive technology devices that can be connected to smartphones include:
Braille Displays: These devices convert on-screen text into Braille characters. Smartphones can connect to Braille displays via Bluetooth or USB, allowing visually impaired users to read and interact with content.
Switch Control Devices: Switches, which can be buttons, joysticks, or other input devices, are used by individuals with limited mobility. Smartphones often support switch control features that allow these devices to be connected via Bluetooth or USB, enabling users to control their phones.
Eye-tracking Systems: Some smartphones support eye-tracking technology, allowing users to control their devices using eye movements. External eye-tracking devices can be connected to smartphones to enable this functionality.
Augmentative and Alternative Communication (AAC) Devices: These devices assist individuals with speech or communication difficulties. AAC devices can connect to smartphones to facilitate communication through specialized apps or interfaces.
Hearing Aid Compatibility: Smartphones often have features that support direct connectivity with hearing aids via Bluetooth. This enables users with hearing impairments to stream audio directly to their hearing aids from their phones.
Adaptive Keyboards and Input Devices: External adaptive keyboards or input devices designed for specific needs, such as larger keys or specialized input methods, can connect to smartphones via Bluetooth or USB.
This guideline could have been appropriate under the 'Robust' principle. Still, since the lack of support for external devices would make it difficult or impossible for some users to operate the application, or parts of it seemed more prominent, it was finally associated with the operable principle.
Success Criterion 2.2.1. External aids and devices
The application's content and functionality are operable through the interface of any external assistive technology supported by the user's device.
Test
Impact
Notes
If a smartphone device supports the connection of an external assistive technology device, users can reach and operate controls and other interactive elements of the UI through the assistive technology.
This guideline deals with providing users enough time to read and use content.
Success Criterion 2.3.1. Adjustable Time Limits
For actions and tasks of the user with a time limit for their completion, the time limitation can be turned off, adjusted, or extended.
Test
Impact
Notes
For any UI operation or event with a time limit requiring user attention or input, at least one of the following is true:
The user can turn off the time limit, or
The user can adjust the time limit in advance (i.e., before the task execution timer has started running) to at least ten times the default time provided, or
The user can extend the default time limitation at least ten times. If a time extension mechanism is provided, users should be informed at least 20 seconds before the time is up.
Except when: The time limit is essential, and not respecting it would invalidate the activity (like an auction).
Serious
Mechanisms to pause, adjust, or extend the time limit can be operated with a simple action like a single tap.
For any content that starts moving, blinking, or scrolling automatically for more than five seconds, there is a mechanism for the user to pause or stop it.
Test
Impact
Notes
Content in the UI that automatically moves blinks, or scrolls has a corresponding mechanism to pause or stop the content’s motion or changes.
Serious
Mechanisms to pause, or stop content’s motion or changes can be operated with a simple action like a single tap.
Users can stop or control the update frequency of auto-updating content.
Test
Impact
Notes
For any content that is frequently auto-updating, there is a corresponding mechanism to stop, pause, or control the frequency of the update, except when:
the auto-updating is essential for the activity (airline flights board, for example)
This guideline deals with phenomena and elements in the UI that, due to the nature of their display, may trigger seizures and physical reactions for some users.
Success Criterion 2.4.1. Flashing Content
Content on the screen does not include anything that flashes more than three times per second.
Test
Impact
Notes
Content does not include elements, texts, or graphics that flash on the screen three times or more per second.
Serious
Flashing content does not include deep or saturated red hue
This guideline addresses the ability of users to quickly and intuitively navigate to any control area and content in the user interface with any user agent or assistive technology supported by the device.
Success Criterion 2.5.1. Bypass Blocks
If any essential content or features are sequentially located after lengthy content lists, such as feeds, product catalogs, or search results, enable direct access for users to navigate to them quickly.
Test
Impact
Notes
Users can reach essential elements and content using the quick access features of screen readers' “Accessibility Navigation Menus” or similar technology.
Screens or components do not require two-dimensional scrolling unless it is essential for the content or functionality.
Test
Impact
Notes
Screens and components do not require two-dimensional scrolling, except when:
Two-dimensional scrolling is essential for understanding the content or the application's functionality (e.g., maps, diagrams, large data tables, games)
This guideline deals with issues related to the ability of users to perceive and understand their location in the application or specific screen and the context in which they navigate.
Success Criterion 3.1.1. Screen Titled
Ensure that the mobile application's pivotal screens or primary views, which convey essential information or denote significant content changes, have clear and descriptive textual identifier.
Test
Impact
Notes
The screen has a title that's announced by screen readers when the screen loads.
Content and interactive elements follow a logical reading sequence that facilitates comprehension and effective interaction for assistive technology users.
Test
Impact
Notes
The programmatic order of elements makes sense and reflects the content hierarchy of the screen.
Serious
Ensure assistive technologies solely identify and interact with intended content, excluding non-essential or supplementary nodes within the hierarchy.
Ensure that the focus order within mobile applications follows a logical and intuitive sequence, facilitating efficient navigation and interaction for users utilizing keyboard navigation or other input methods.
Test
Impact
Notes
The order in which elements receive focus in sequential navigation maintains a logical flow and avoids erratic jumps across the screen.
Elements forming a single context unit are grouped so they are parsed and announced by assistive technologies as a single element.
Test
Impact
Notes
When browsing through the screen with a screen reader or a similar assistive technology, ensure that elements that assemble a single context (e.g., a button, its text, and its icon or an image and its caption) are announced as one unit and that each of its parts is not announced separately.
This guideline deals with elements' identifying names and text alternatives in terms of content clarity and the validity of the technical implementation of the name or label.
Success Criterion 3.2.1. Meaning and Purpose
Names and labels of user interface elements, with an emphasis on interactive elements, should reflect their meaning and purpose independent of their visual context.
Test
Impact
Notes
Accessible name clearly conveys the purpose of elements in context
Critical
Accessible name clearly conveys the purpose of elements always
Success Criterion 3.2.2. Appropriate Text Alternatives
The text alternatives of images and media elements should be descriptive, and their phrasing should be appropriate to the element's purpose as described in the W3C's Images Tutorial.
When text is scaled to the maximum size allowed by the operating system, it is not clipped, obscured, overlapped, or covered by other texts or elements.
Test
Impact
Notes
Text lines do not exceed the viewport width, causing a two-dimensional scroll.
Range between Moderate and SeriousModerate → Serious
Spaces between paragraphs (on subsequent paragraphs) should be at least two tines of the line spacing
This guideline deals with users' ability in general and assistive technology users in particular to predict the behavior of the interface, its components, and the outcome of operating them.
Success Criterion 3.4.1. Locale and Human Language
The application's locale is compatible with the human language of the texts within the app.
Test
Impact
Notes
The application’s locale code matches the human language in the application.
Success Criterion 3.4.2. Context Kept on User Input
The user remains on the current screen (or context), and the content and structure remain consistent when an element gains focus or due to user-initiated 'on-change' events.
Test
Impact
Notes
Users remain in the same context (i.e., screen, modal, alerts) when they enter or update values in controls and form elements, except when:
Users are informed about the context change up front.
Critical
No significant content or structure changes occur when users enter or update values in controls and form elements, except when:
The changes are due to filtering or sorting actions, and
Users can predict the changes, and
The location of the focus and assistive technologies in the UI is kept
Serious
Users remain in the same context (i.e., screen, modal, alerts) when they shift the focus to any control or form element
Critical
No significant content or structure changes occur when users shift the focus to any control or form element
If a help mechanism (e.g., chat) or a link to a help center exists, they should appear in a consistent location and have the exact identifying name across all screens.
Test
Impact
Notes
Help mechanisms and help center links are visually located consistently across all screens.
Moderate
Help mechanisms and help center links are programmatically located consistently across all screens.
Moderate
Help mechanisms and help center links have exact identifying names across all screens.
At least one mechanism is provided to users to confirm or correct user inputs or reverse the submission of any action involving financial transactions, legal commitments, or authorization to access or change user data.
Test
Impact
Notes
When users submit any action involving financial transactions, legal commitments, or authorization to access or change data owned by users, at least one of the following is true:
There is a mechanism that validates the user inputs and provides an option to correct errors or
The user can check and confirm the data before executing the transaction or
Users are not asked to re-enter the exact details within the same process, such as completing a purchase or an order.
Test
Impact
Notes
Within a process that requires the user to enter the exact information more than one time after the user provides the data once, at least one of the following is true:
Fields are auto-populated or
The user can choose to auto-populate the fields
Except when:
the information is required to ensure the security of the content or
the previously entered information is no longer valid.
User authentication processes do not require cognitive function tests (such as remembering a password or solving a puzzle) unless this step is an alternative or the test is to recognize objects.
Test
Impact
Notes
In a user authentication process, if one of the steps involves a cognitive function test, at least one of the following is true:
There is an alternative 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.
The cognitive function test is to recognize objects.
The test is to identify visual content (non-text) the user provided.
Range between Serious and CriticalSerious → Critical
This principle ensures that content is robust enough to be interpreted by a wide variety of user agents, including assistive technologies.
Guideline 4.1. Adjustable
This guideline deals with applications' adjustability to user settings from the operating system or the device.
Success Criterion 4.1.1. Text Scaling
All text sizes in the UI are updated and adjusted to the text size set by the user in the operating system's settings.
Test
Impact
Notes
In the operating system settings (typically under accessibility), increase the font size to the maximum. The application's texts should resize proportionally according to the user's settings.
The UI and content are adaptive to the operating system's color modes, such as dark and inverted color modes.
Test
Impact
Notes
For each display mode supported by the operating system, the UI and its content, including UI elements, texts, and images of text, are adaptive to display mode changes.