About MCAG
What is MCAG?
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.
Consider as a proposal for uniform guidelines for the accessibility of native mobile apps that will not necessarily depend on the platform or the application's underlying technology.
The MCAG is formed inspired by the Web Content Accessibility Guidelines (WCAG), and it is based on it while striving to fill the gaps in the WCAG regarding mobile apps, specifically native apps, and to make the necessary adjustments to emphasize the challenges and accessibility issues typical on mobile applications.
See the GitHub repository
The motivation behind this initiative
This initiative had several motives. It started as an internal experiment within Evinced to map how the WCAG applies to native mobile applications, firstly to improve our own tests; and secondly as an answer to customers and prospects whose apps are mandated for compliance, and who wanted to know what level of coverage they would receive and what gaps would remain for manual testers.
One of the results of this experiment was the realization that it is impossible to benchmark the accessibility of mobile apps to WCAG without also ignoring vendors' accessibility guidelines, even if they are not as comprehensive as WCAG and sometimes also coincide with it; they do contain specific references to mobile technologies and some of their accessibility challenges which naturally are not reflected in WCAG. With this understanding, the initial idea was formed to produce tailored guidelines for mobile applications based on cross-referencing information from several sources.
Therefore, with the understanding and belief that we are not the only ones who face the challenges and questions that arise in the context of how WCAG applies to native mobile applications, and the recognition that in order to establish significant and sustainable guidelines that develop and update with the technology, we decided to publish this first draft as a proposal for a starting point of a discussion and with the aim companies and community members who see value in such guidelines will join and contributed their knowledge and experience in the development of the initiative. The first goal is to provide guidelines mapped to WCAG that will allow easy analysis of the level of compliance of mobile apps with WCAG and hopefully will later be adopted as a separate and dedicated standard.
Do we really need another set of accessibility guidelines?
WCAG is designed for web technologies and practices
WCAG has been adopted as the primary benchmark for digital accessibility by regulators, and rightly so. Even if it is imperfect, the WCAG is detailed and comprehensive, its success criteria were discussed and tested comprehensively, and most importantly, it provides a set of testable requirements and a ranking method to determine the accessibility level of web-based pages.
Because of the advantages mentioned above, the inherent similarities between web and mobile technologies in terms of display and consumption of information and user input, and the fact that many of the WCAG success criteria deal with common accessibility issues in mobile apps and digital media in general, and not necessarily unique to web technologies it has naturally been adopted as the benchmark for the accessibility of mobile apps as well.
For example, this trend can be seen in the European standard (EN 301 549) in chapter 11, which deals with software and mobile applications directly referring to WCAG 2.1 AA. A similar reference can also be seen in the reports of products for accessibility testing (due disclosure also those of Evinced) and the need and strive of the app owners to confirm a standard according to which they know that their products are sufficiently accessible and meet the requirements that will protect them from lawsuits. However, in all of these cases, it can be seen that the conformity of WCAG to mobile app accessibility requirements is not complete; not all WCAG success criteria are mapped to mobile equivalents, and there are issues specific to mobile that WCAG does not cover, such as content grouping and some of its success criteria are phrased in direct reference to the web technologies and an interpretation is required to adapt them to mobile as for example in 1.4.10 Reflow or 1.4 .12 Text Spacing. The WCAG naturally refers widely to the keyboard since it is the most essential assistance technology for the web. On the other hand, it is less prevalent in mobile while supporting standard accessibility features of mobile devices is not considered or addressed.
For the question of whether it expected to see more criteria referencing issues typical to mobile apps in WCAG 3 (in the first announcements on WCAG 3, there was a statement of intent that it would be suitable for digital media in general), the answer was that despite the initial intention it was decided in the W3C that since the W in the acronym stands for "web," the WAI will continue focusing exclusively on web technologies. Hence, the inherent gaps in WCAG about mobile applications will remain. These circumstances leave gray areas and room for interpretation regarding the accessibility requirements that will fit the technology and potential issues that are typical to the technology not addressed.
Don't mobile accessibility guidelines already exist?
Suppose one is Googling "accessibility guidelines for mobile apps" or, even more specifically, for iOS or Android apps. In that case, they will get many results ranging from vendor guidelines such as Apple's Human Interface Guidelines and developer documentation's accessibility chapters or the Android Accessibility Principles to guidelines written by accessibility professionals like AccessibilityOZ, which focus on testing methodologies and checklists. The Funka Nu organization also published accessibility guidelines for mobile apps. However, the phrasing of these guidelines is at a relatively general level. It does not go down to the details of testable, measurable use cases that allow presenting a uniform standardization.
WAI also attempted to map WCAG 2.1 to meet the specific requirements for mobile web written by the WAI's Mobile Accessibility Task Force. They published the first public working draft of "Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile" in February 2015 and an editor's draft in December 2018; however, there have been no other updates since then, and it seems like the project was abandoned; in any case, this mapping was designed for mobile web and not for native apps so it is not impossible that some of the gaps would still have remained and that some issues would potentially still stay unaddressed.
However, this knowledge and ideas have never been distilled to a uniform standard that is required given the place that mobile has occupied in our lives and the specific accessibility challenges of the technology.
Hence, the primary objective of this MCAG draft is to cross-reference principles and concepts from the sources mentioned above and others and map them to testable use cases similar to WCAG.
The writing process of this draft
The writing process of this draft began in a thinking group participated by product managers, mobile developers and architects, designers, researchers, and accessibility professionals. The objective of this thinking group was to map which WCAG success criteria are valid for mobile applications, where for each success criterion, it was indicated whether it applies to mobile as it is phrased or only in spirit; that is, that its fundamental essence suitable for mobile, however, a particular interpretation is required for it to suit the accessibility challenges typical to mobile.
The second stage was cross-referencing WCAG's success criteria with the vendors' guidelines and documentation (i.e., iOS and Android), which helped to distill the common and clarify what adjustments are required to start accurate success criteria.
The third stage was cross-referencing all the guidelines with various other sources (the primary list of sources later). In parallel and with the understandings that have been formulated, several outline versions were experimented with until they were crystallized into the draft proposed here.
Target audience and personas
We believe that the key to the development of accessible products is understanding both the accessibility challenges and the requirements of all those in positions throughout the product's life cycle. This draft was written to be readable and transparent primarily to the members of the research and development teams, starting with the product manager through the UI/UX designers and developers to QA testers. Secondarily, this guideline is intended to be used by by accessibility professionals.
This text is intended for a technical audience, but also to be relatively easy to read for a general audience.
We have defined four personas that we believe are MCAG's primary target audienceof software development teams:
The personas
Product Manager
Name: Alex Morgan
Role: Product Manager - Native Mobile App (iOS and Android)
Background:- Alex has five years of experience in product management, specializing in mobile applications.
- Proficient in agile methodologies, Alex has successfully launched several mobile apps across different platforms.
- Holds a strong understanding of user experience (UX) design principles and product development processes.
- Committed to ensuring the app's success by meeting not only business goals but also user needs and regulatory requirements.
- Oversees the development and enhancement of a native mobile application available on both iOS and Android platforms.
- Collaborates with cross-functional teams, including developers, designers, and QA, to plan and prioritize features, enhancements, and bug fixes.
- Works closely with stakeholders to define and achieve business objectives while meeting user requirements.
- Responsible for ensuring the app meets accessibility standards and regulations.
- Ensure the app's features are seamlessly implemented across both iOS and Android platforms while maintaining consistency and optimal user experience.
- Strive to enhance the app's accessibility, ensuring it complies with WCAG and platform-specific accessibility standards.
- Manage the product roadmap, balancing business objectives with user needs and accessibility compliance.
- Requires clear communication and collaboration among teams to ensure the app's accessibility features are well-integrated without compromising the app's functionality or design.
- Prefers data-driven decisions, relying on analytics and user feedback to drive product enhancements.
- Seeks to leverage tools and resources to streamline accessibility testing and compliance efforts.
"I am dedicated to ensuring our mobile app delivers an inclusive experience for all users. Accessibility is not just a compliance issue; it is about creating an app that's usable and beneficial for everyone."
UI and UX Designer
Name: Sarah Hayes
Role: UI/UX Designer - Mobile Applications
Background:- Sarah holds a Bachelor's degree in Graphic Design with five years of experience specializing in mobile app design.
- Possesses a strong portfolio demonstrating expertise in creating intuitive and visually appealing user interfaces.
- Has recently undertaken additional training in accessible design principles, striving to incorporate accessibility into every aspect of the design process.
- Keeps updated with the latest trends, tools, and guidelines related to mobile app accessibility.
- Leads the design process for mobile applications, ensuring a seamless and intuitive user experience.
- Collaborates closely with cross-functional teams, including developers, product managers, and testers, to translate concepts into user-friendly designs.
- Advocates for accessibility in design, striving to integrate accessible features and elements from the initial design stages.
- Create visually engaging and accessible designs that cater to users of all abilities, ensuring compliance with accessibility standards such as WCAG and platform-specific guidelines.
- Strive to maintain a balance between aesthetic appeal and accessibility, advocating for designs that are both visually appealing and functional for all users.
- Collaborate effectively with other team members to ensure that design concepts seamlessly translate into accessible and user-friendly mobile interfaces.
- Seeks clarity in accessibility guidelines and standards, preferring resources and tools that aid in implementing accessible design practices.
- Values user feedback and usability testing, relying on insights from real users to refine and improve designs.
- Prefers collaboration and open communication within the team to ensure that accessibility considerations are integrated into every stage of the design process.
"Designing for accessibility isn't just about compliance; it's about creating inclusive experiences that empower all users to interact with our app comfortably and effectively."
Developer
Name: Chris Reynolds
Role: Mobile App Developer - Native Platforms (iOS and Android)
Background:- Chris holds a degree in Computer Science with seven years of experience specializing in mobile app development.
- Proficient in iOS and Android app development, leveraging languages like Swift, Kotlin and platforms like Xcode and Android Studio.
- Actively seeks to enhance knowledge of accessibility standards and inclusive design principles, understanding the importance of sustainable accessibility in app development.
- Committed to writing clean, maintainable code and ensuring app features remain accessible through software updates.
- Develops and maintains native mobile applications, ensuring functionality and optimal performance across iOS and Android platforms.
- Collaborates closely with designers, product managers, and quality assurance teams to translate design concepts into functional and accessible mobile app features.
- Integrates accessibility features into the app architecture, striving to maintain accessibility standards through software updates and enhancements.
- Ensure that the mobile app meets accessibility guidelines such as WCAG, platform-specific standards, and user expectations for inclusivity.
- Strive to maintain app accessibility and functionality through software updates by adopting best practices and adhering to sustainable accessibility principles.
- Overcome challenges in balancing new feature development, code optimization, and ensuring accessibility compliance without compromising user experience.
- Requires clear guidelines and resources for integrating sustainable accessibility features into the app's architecture.
- Prefers access to tools and frameworks that streamline accessibility testing and verification during the development process.
- Values collaboration and communication among cross-functional teams to ensure sustainable accessibility considerations throughout the app's lifecycle.
"Building and maintaining accessible apps is not just about meeting standards; it's about ensuring our app remains inclusive and usable for all users, even as we evolve and enhance its features."
QA Tester
Name: Emily Carter
Role: QA Tester - Native Mobile Applications
Background:- Emily has a Bachelor's degree in Computer Science and three years of experience in quality assurance and testing, specializing in mobile app testing.
- Proficient in using testing tools and methodologies for iOS and Android platforms, ensuring app functionality and quality.
- Has a basic understanding of accessibility principles but is not an accessibility expert.
- Committed to learning and understanding how to test for accessibility within mobile applications.
- Conducts quality assurance testing for native mobile applications, verifying functionality, usability, and performance across different devices and platforms.
- Ensures that app features, functionalities, and user interfaces meet design and functional specifications.
- Responsible for conducting basic accessibility testing to identify and report common accessibility issues within the app.
- Strives to verify that the mobile app meets basic accessibility standards and guidelines despite not having in-depth expertise in accessibility testing.
- Seeks to learn and apply fundamental accessibility testing methods to identify and report common accessibility issues.
- Faces challenges in understanding complex accessibility guidelines and interpreting them to conduct effective accessibility testing.
- Requires guidance and training on basic accessibility testing techniques and tools relevant to mobile applications.
- Prefers clear documentation or guidelines explaining common accessibility issues and how to identify them during testing.
- Values collaboration with developers, designers, and accessibility experts to learn and improve accessibility testing practices.
"I aim to ensure our mobile apps are usable for everyone, even though I'm not an accessibility expert. Learning how to conduct basic accessibility testing helps me contribute to making our apps more inclusive."
Among the four personas described above, there is no one whose primary concern is accessibility. However, all four must refer to accessibility and inclusiveness of the UI and the challenges to incorporate them, each of the persona in its own field and part of the life cycle of the application; therefore, each of them can benefit from dedicated accessibility guidelines for mobile apps, both in their own work and in collaborations with other roles in the product's lifecycle.
For example:
- Provides clear standards and benchmarks for app accessibility, aiding in setting goals and expectations for inclusive design.
- Offers specific criteria and best practices tailored to mobile apps, assisting in prioritizing accessibility features and ensuring compliance across platforms.
- Provides detailed guidelines specific to mobile apps, aiding in creating intuitive and accessible designs that comply with industry standards.
- Offers clarity on accessibility features and considerations, facilitating the integration of inclusive design elements into the app's UI/UX.
- Offers clear specifications and coding practices for implementing accessible features, streamlining development efforts and ensuring sustainable accessibility through software updates.
- Provides guidance on integrating accessibility features into the app's architecture, aiding in maintaining app accessibility across different mobile platforms.
- Provides standardized testing criteria and methodologies specific to mobile app accessibility, aiding in conducting more effective and consistent accessibility testing.
- Offers clear guidelines and documentation on common accessibility issues, facilitating identifying and reporting accessibility concerns during testing.
Dedicated and uniform accessibility guidelines for native mobile apps benefit these personas by offering clear standards, specific criteria, and detailed guidance relevant to their respective roles, so their ability to read and thoroughly understand such guidelines is essential.
Supporting documents
Terminology
The Terminology page contains definitions, interpretations, and clarifications for concepts and terms in the guidelines' body. The terms on the page are sorted alphabetically and not by their topic.
Formulas for measurement units conversion
The Conversion Formulas page. The different mobile platforms use different measurement units, and these are usually relative and depend on the device's pixel density. In the guidelines there are success criteria and tests that require size reference, this page contains conversion formulas that should help users convert the units defined in the tests or success criteria. Each success criterion page that requires dealing with size or area has a link to this page.The formulas in this page were created based on data from the Android and iOS developer documentation and with the assistance of ChatGPT.