The Web Content Accessibility Guidelines may have been designed to be applicable to all technologies, but it still uses terminology and measures specific to web technology. So, how do we ensure our native mobile apps conform to standards and guidelines? Jon will show us how he tests native apps to such standards.
Organizations are looking for mobile accessibility standards but is mobile different than desktop? Learn about is new in WCAG 2.1, Europe and around the world.
A small introduction about WAI-ARIA where I show its 5 rules and 2 related attributes to improve the web accessibilty into the world. Helped by some facts related to the status of Web accessibility.
Talk had at the FrontEnders Ticino monthly meetup in Bellinzona (Switzerland) on the Global Accessibility Awareness Day (official supporter)
Practical tools for Web Accessibility testingToufic Sbeiti
There is no single tool that does a full accessibility assessment of a web page. Developers use a variety of tools to help them evaluate websites. This is a practical talk with lots of demos. I will share my favorites, free and easy to use, tools to measure the level of accessibility of web page.
If a website or mobile app is not accessible to all potential visitors, is it truly a quality product? Services, products, information, and entertainment on the web and mobile devices can be made available to millions of consumers with vision, hearing, or motor control difficulties by complying with accessibility standards. Assistive technologies enable access by converting the text and images of mobile screens and web pages into computerized voice. But these technologies cannot interpret pages that are not built and tested for compliance to accessibility standards and programming guidelines. Join Nancy Kastl to learn about Section 508 and WCAG standards, Mobile Web Best Practices, and Apple and Android Developer Accessibility Guidelines. Learn how to test for accessibility on mobile devices and desktop using screen readers and open source tools. Become an advocate of accessible mobile apps and websites throughout the project lifecycle and add accessibility testing to your testing capabilities.
Incorporating accessibility into your software.
What does accessibility mean?
Why should we do this?
How we should do this?
What impacts does this have?
Organizations are looking for mobile accessibility standards but is mobile different than desktop? Learn about is new in WCAG 2.1, Europe and around the world.
A small introduction about WAI-ARIA where I show its 5 rules and 2 related attributes to improve the web accessibilty into the world. Helped by some facts related to the status of Web accessibility.
Talk had at the FrontEnders Ticino monthly meetup in Bellinzona (Switzerland) on the Global Accessibility Awareness Day (official supporter)
Practical tools for Web Accessibility testingToufic Sbeiti
There is no single tool that does a full accessibility assessment of a web page. Developers use a variety of tools to help them evaluate websites. This is a practical talk with lots of demos. I will share my favorites, free and easy to use, tools to measure the level of accessibility of web page.
If a website or mobile app is not accessible to all potential visitors, is it truly a quality product? Services, products, information, and entertainment on the web and mobile devices can be made available to millions of consumers with vision, hearing, or motor control difficulties by complying with accessibility standards. Assistive technologies enable access by converting the text and images of mobile screens and web pages into computerized voice. But these technologies cannot interpret pages that are not built and tested for compliance to accessibility standards and programming guidelines. Join Nancy Kastl to learn about Section 508 and WCAG standards, Mobile Web Best Practices, and Apple and Android Developer Accessibility Guidelines. Learn how to test for accessibility on mobile devices and desktop using screen readers and open source tools. Become an advocate of accessible mobile apps and websites throughout the project lifecycle and add accessibility testing to your testing capabilities.
Incorporating accessibility into your software.
What does accessibility mean?
Why should we do this?
How we should do this?
What impacts does this have?
Documentation management system & information databasesSyed Zaid Irshad
A document management system (DMS) is a computer system (or set of computer programs) used to track and store electronic documents and/or images of paper documents.
Web accessibility 101: The why, who, what, and how of "a11y"ecentricarts
Our in-house ecentricarts Accessibility Team (known as EAT) has compiled a ton of resources to help you understand the ins and outs of web accessibility. This includes: why it matters, who it impacts, common misconceptions, a beginner's guide to WCAG 2.0 and accessibility legislation, and how you can test, design, develop, and create more accessible websites.
This presentation also includes examples of before/after screenreader demos, and our 2017 company video made with described audio.
Accessibility is not a rare edge case, it is something that concerns all of us. This is an introduction to Web Accessibility for Web Developers, in context of the German BITV and the international WAI Guidelines (mostly WCAG 2.0). It should raise general awareness of accessibility for Web Development, and shows that accessibility is not an extreme hard to implement requirement, but a matter of care and common sense.
Understanding and Supporting Web AccessibilityRachel Cherry
Web accessibility refers to the inclusive practice of removing barriers that prevent interaction with, or access to, websites by people with disabilities. When your website is accessible, all users can access your content and functionality no matter their abilities. Visually-impaired users can visit your website using a screen reader. Those who can’t use a mouse can navigate your site using a keyboard or other input device. Most accessibility features will also improve your SEO.
When your site is inaccessible, research shows you could be excluding up to 20 percent of your users.
This talk will cover the basics of accessibility, why it’s important, and how you can support accessibility in your projects.
A beginners guide to accessibility testing. An overview of common mistakes websites make and highlighting some easy to use tools that anyone can incorporate into their work.
Presented at www.AccessibilityCalgary.com on May 12, 2013.
Learn about the basics of web accessibility: what it is, who it affects, why it matters, and some of the fundamental things you ought to be doing in your pages to make them more accessible.
This is an android application for tourists. This application helps in solving their problem of understanding regional language and finding nearby places.
Game development using HTML5 technologies presentation, May 2010.
This lecture was given by Gil Megidish at AlphaGeeks #6 meetup in Tel Aviv, Israel.
The talk begins with some review of the game graphics techniques, and how you can achieve these with today's browsers and client side code.
4 demos were presented: sprites with canvas (luigi), framebuffer access (apple2 emulator), primitives and polygons (another world js) and image modifiers (droste effect.)
The lecture was given in Hebrew, ppt is English.
Applying EU regulation to native mobile apps (IAAP webinar, December 2021)Jon Gibbins
Modern digital accessibility standards are designed to be applicable to all technologies, but they need translating for use in different technical contexts. This is particularly true for native mobile platforms, such as iOS and Android, where terminology and measures specific to web technology do not necessarily translate easily. So, how do we conform to the EU Web Accessibility Directive when working with native mobile apps? Jon will explain how he translates these accessibility standards for native mobile apps.
10 quick tests to enhance your site’s accessibilityToufic Sbeiti
In this presentation, I talk about 10 tests that can be performed quickly without any coding skills to measure the accessibility of a web page. If you are a developer, you can fix before posting live. If you are a project manager or a client, you can ensure the level of accessibility without advanced coding knowledge.
Documentation management system & information databasesSyed Zaid Irshad
A document management system (DMS) is a computer system (or set of computer programs) used to track and store electronic documents and/or images of paper documents.
Web accessibility 101: The why, who, what, and how of "a11y"ecentricarts
Our in-house ecentricarts Accessibility Team (known as EAT) has compiled a ton of resources to help you understand the ins and outs of web accessibility. This includes: why it matters, who it impacts, common misconceptions, a beginner's guide to WCAG 2.0 and accessibility legislation, and how you can test, design, develop, and create more accessible websites.
This presentation also includes examples of before/after screenreader demos, and our 2017 company video made with described audio.
Accessibility is not a rare edge case, it is something that concerns all of us. This is an introduction to Web Accessibility for Web Developers, in context of the German BITV and the international WAI Guidelines (mostly WCAG 2.0). It should raise general awareness of accessibility for Web Development, and shows that accessibility is not an extreme hard to implement requirement, but a matter of care and common sense.
Understanding and Supporting Web AccessibilityRachel Cherry
Web accessibility refers to the inclusive practice of removing barriers that prevent interaction with, or access to, websites by people with disabilities. When your website is accessible, all users can access your content and functionality no matter their abilities. Visually-impaired users can visit your website using a screen reader. Those who can’t use a mouse can navigate your site using a keyboard or other input device. Most accessibility features will also improve your SEO.
When your site is inaccessible, research shows you could be excluding up to 20 percent of your users.
This talk will cover the basics of accessibility, why it’s important, and how you can support accessibility in your projects.
A beginners guide to accessibility testing. An overview of common mistakes websites make and highlighting some easy to use tools that anyone can incorporate into their work.
Presented at www.AccessibilityCalgary.com on May 12, 2013.
Learn about the basics of web accessibility: what it is, who it affects, why it matters, and some of the fundamental things you ought to be doing in your pages to make them more accessible.
This is an android application for tourists. This application helps in solving their problem of understanding regional language and finding nearby places.
Game development using HTML5 technologies presentation, May 2010.
This lecture was given by Gil Megidish at AlphaGeeks #6 meetup in Tel Aviv, Israel.
The talk begins with some review of the game graphics techniques, and how you can achieve these with today's browsers and client side code.
4 demos were presented: sprites with canvas (luigi), framebuffer access (apple2 emulator), primitives and polygons (another world js) and image modifiers (droste effect.)
The lecture was given in Hebrew, ppt is English.
Applying EU regulation to native mobile apps (IAAP webinar, December 2021)Jon Gibbins
Modern digital accessibility standards are designed to be applicable to all technologies, but they need translating for use in different technical contexts. This is particularly true for native mobile platforms, such as iOS and Android, where terminology and measures specific to web technology do not necessarily translate easily. So, how do we conform to the EU Web Accessibility Directive when working with native mobile apps? Jon will explain how he translates these accessibility standards for native mobile apps.
10 quick tests to enhance your site’s accessibilityToufic Sbeiti
In this presentation, I talk about 10 tests that can be performed quickly without any coding skills to measure the accessibility of a web page. If you are a developer, you can fix before posting live. If you are a project manager or a client, you can ensure the level of accessibility without advanced coding knowledge.
WCAG 2.1 has 17 additional criteria - most of them with design implications. These slides attempt to assign responsibility to visual designers, interaction designers and content designers as appropriate.
Many of the new WCAG 2.1 criteria have implications for designers: graphics, content and UX. In this presentation from the 2018 OZeWAI Conference, Senior Digital Accessibility Consultant Andrew Arch will discuss relevant criteria from a design perspective and identify who needs to take responsibility for what.
Historically, VPATs or (Accessibility Conformance Reports) have been the way in which to measure and document compliance with a number of standards including (WCAG, US 508, and EN 301 549). Companies which produce many products often produce many VPATs to help meet the needs of customers and internal stakeholders. Within VPATs, there is a wealth of data generated that, if fully leveraged, can provide insights into a company’s accessibility estate. Data can be derived from VPATs such as the distribution of checkpoints that are fully, partially, and not supported. This data can be mined, aggregated, and sliced in ways to help provide larger insights. Elsevier has a large number of products, and we used this data analytics approach to compare and rank using data from dozens of accessibility evaluations. We will share the story of why this became necessary for us, and the eventual decisions that led to our current iteration. We will also go over the benefits of ranking products against each other and how it breeds competitiveness, especially in an organization that takes accessibility seriously. We will also share the success stories of how this comparison has driven accessibility remediation efforts across numerous products. We will also go over the limitations of these analytics and any current issues they still have.
www.earnperhit.com/essay => Professional academic writing
www.Lucky-Bet.site => Bet on Sports - 50% Deposit Bonus
www.Lucky-Bet.site/casino => Online Casino - 5000$ Welcome Bonus
www.Lucky-Bet.site/lotto247 => Lotto247 - Win Big, Live Free
www.Lucky-Bet.site/eurobet => Best European Bookmaker
You may have accessible web templates, but what happens when your content authors add or update content? This enduring problem now has broader implications because the Web Content Accessibility Guidelines have expanded to allow the use of non-HTML technologies.
This is a presentation given at a Web Accessiblity for Australian Universities (WANAU) forum in Melbourne in September, 2009. It provides an overview of the issues web writers will need to be aware of as organisations move to adopt WCAG 2.0.
Similar to Native mobile accessibility testing: compliance, tools and tips (Funka Accessibility Days, November 2020) (7)
Your small business meets sustainability (webinar for The ICG, October 2021)Jon Gibbins
Webinar discussing the themes of sustainability, ethical finance and green technology, and include toolkit suggestions, helpful advice and achievable changes you can start using today.
https://theicg.co.uk/event/your-small-business-meets-sustainability/
Making sustainability accessible (Future Economy Network event, February 2021)Jon Gibbins
If we exclude people in our work, then we create products and services that are less sustainable. And as we look to the future, our idea of what it means to be inclusive and sustainable will shift. Around 1 in 5 people have a disability. We need to include them. We need their help.
Advanced (Undocumented) iOS accessibility techniques (iOSDevUK, September 2019)Jon Gibbins
Perhaps you know some accessibility basics, but what about the more advanced stuff? iOS provides a powerful API for creating accessible user experiences, and some implementations certainly have their quirks. This talk covers this trickier end of the spectrum.
Experiencing digital accessibility using your smartphone (Bristol ID&D, June ...Jon Gibbins
Getting your own experience of accessibility helps you to put yourself in the shoes of others and keep accessibility in mind when designing and developing. Find out how you can easily experience accessibility for yourself using something you likely have in your pocket – a smartphone.
Experiencing digital accessibility (FEL 2018)Jon Gibbins
If empathy is about understanding people, accessibility is about understanding people and the barriers that they face. Getting your own experience of accessibility helps you to put yourself in the shoes of others and keep accessibility in mind when building and testing your sites and applications.
In this talk, Jon Gibbins gives a practical introduction to accessibility for front end designers and developers. He will walk through some typical accessibility barriers and situations where an accessible user experience does not necessarily come from simply adhering to accessibility guidelines. Find out how you can easily experience accessibility for yourself using something you likely have in your pocket – a smartphone. Leave with some tips under your belt and a grasp of some technical fundamentals that are often the missing piece of the puzzle for developers' understanding of accessibility.
iOS and Android accessibility APIs (AccessU 2017)Jon Gibbins
A guided tour of the native accessibility APIs on iOS and Android to help you understand what’s possible and learn how to speak accessibility to iOS and Android app developers.
This primer on mobile accessibility will give you a solid grounding on standards, guidelines and principles of making websites accessible on mobile devices, and demonstrate some of the accessibility features available on iOS and Android.
This presentation was delivered at Digpen 7:
http://lanyrd.com/2014/digpen7/sdfcth/
Hitting a moving target: achieving mobile inclusionJon Gibbins
Mobile interaction and use is narrowing the digital divide, providing new opportunities for digital inclusion around the world. Mobile platforms such as iOS, Android, and Windows are rapidly evolving with richer and more robust accessibility features and support, giving developers more ways to create accessible mobile web applications.
This presentation was delivered at e-access '13:
http://www.headstar.com/eaccess13/agenda.html
Online presentation:
http://www.w3.org/People/shadi/Talks/2013/1031/Mobile/
Or:
https://dl.dropboxusercontent.com/u/64311/training/2013-eaccess-553d7c/index.html
Quarkus Hidden and Forbidden ExtensionsMax Andersen
Quarkus has a vast extension ecosystem and is known for its subsonic and subatomic feature set. Some of these features are not as well known, and some extensions are less talked about, but that does not make them less interesting - quite the opposite.
Come join this talk to see some tips and tricks for using Quarkus and some of the lesser known features, extensions and development techniques.
May Marketo Masterclass, London MUG May 22 2024.pdfAdele Miller
Can't make Adobe Summit in Vegas? No sweat because the EMEA Marketo Engage Champions are coming to London to share their Summit sessions, insights and more!
This is a MUG with a twist you don't want to miss.
A Study of Variable-Role-based Feature Enrichment in Neural Models of CodeAftab Hussain
Understanding variable roles in code has been found to be helpful by students
in learning programming -- could variable roles help deep neural models in
performing coding tasks? We do an exploratory study.
- These are slides of the talk given at InteNSE'23: The 1st International Workshop on Interpretability and Robustness in Neural Software Engineering, co-located with the 45th International Conference on Software Engineering, ICSE 2023, Melbourne Australia
Prosigns: Transforming Business with Tailored Technology SolutionsProsigns
Unlocking Business Potential: Tailored Technology Solutions by Prosigns
Discover how Prosigns, a leading technology solutions provider, partners with businesses to drive innovation and success. Our presentation showcases our comprehensive range of services, including custom software development, web and mobile app development, AI & ML solutions, blockchain integration, DevOps services, and Microsoft Dynamics 365 support.
Custom Software Development: Prosigns specializes in creating bespoke software solutions that cater to your unique business needs. Our team of experts works closely with you to understand your requirements and deliver tailor-made software that enhances efficiency and drives growth.
Web and Mobile App Development: From responsive websites to intuitive mobile applications, Prosigns develops cutting-edge solutions that engage users and deliver seamless experiences across devices.
AI & ML Solutions: Harnessing the power of Artificial Intelligence and Machine Learning, Prosigns provides smart solutions that automate processes, provide valuable insights, and drive informed decision-making.
Blockchain Integration: Prosigns offers comprehensive blockchain solutions, including development, integration, and consulting services, enabling businesses to leverage blockchain technology for enhanced security, transparency, and efficiency.
DevOps Services: Prosigns' DevOps services streamline development and operations processes, ensuring faster and more reliable software delivery through automation and continuous integration.
Microsoft Dynamics 365 Support: Prosigns provides comprehensive support and maintenance services for Microsoft Dynamics 365, ensuring your system is always up-to-date, secure, and running smoothly.
Learn how our collaborative approach and dedication to excellence help businesses achieve their goals and stay ahead in today's digital landscape. From concept to deployment, Prosigns is your trusted partner for transforming ideas into reality and unlocking the full potential of your business.
Join us on a journey of innovation and growth. Let's partner for success with Prosigns.
Innovating Inference - Remote Triggering of Large Language Models on HPC Clus...Globus
Large Language Models (LLMs) are currently the center of attention in the tech world, particularly for their potential to advance research. In this presentation, we'll explore a straightforward and effective method for quickly initiating inference runs on supercomputers using the vLLM tool with Globus Compute, specifically on the Polaris system at ALCF. We'll begin by briefly discussing the popularity and applications of LLMs in various fields. Following this, we will introduce the vLLM tool, and explain how it integrates with Globus Compute to efficiently manage LLM operations on Polaris. Attendees will learn the practical aspects of setting up and remotely triggering LLMs from local machines, focusing on ease of use and efficiency. This talk is ideal for researchers and practitioners looking to leverage the power of LLMs in their work, offering a clear guide to harnessing supercomputing resources for quick and effective LLM inference.
Exploring Innovations in Data Repository Solutions - Insights from the U.S. G...Globus
The U.S. Geological Survey (USGS) has made substantial investments in meeting evolving scientific, technical, and policy driven demands on storing, managing, and delivering data. As these demands continue to grow in complexity and scale, the USGS must continue to explore innovative solutions to improve its management, curation, sharing, delivering, and preservation approaches for large-scale research data. Supporting these needs, the USGS has partnered with the University of Chicago-Globus to research and develop advanced repository components and workflows leveraging its current investment in Globus. The primary outcome of this partnership includes the development of a prototype enterprise repository, driven by USGS Data Release requirements, through exploration and implementation of the entire suite of the Globus platform offerings, including Globus Flow, Globus Auth, Globus Transfer, and Globus Search. This presentation will provide insights into this research partnership, introduce the unique requirements and challenges being addressed and provide relevant project progress.
Check out the webinar slides to learn more about how XfilesPro transforms Salesforce document management by leveraging its world-class applications. For more details, please connect with sales@xfilespro.com
If you want to watch the on-demand webinar, please click here: https://www.xfilespro.com/webinars/salesforce-document-management-2-0-smarter-faster-better/
Enterprise Resource Planning System includes various modules that reduce any business's workload. Additionally, it organizes the workflows, which drives towards enhancing productivity. Here are a detailed explanation of the ERP modules. Going through the points will help you understand how the software is changing the work dynamics.
To know more details here: https://blogs.nyggs.com/nyggs/enterprise-resource-planning-erp-system-modules/
AI Pilot Review: The World’s First Virtual Assistant Marketing SuiteGoogle
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
👉👉 Click Here To Get More Info 👇👇
https://sumonreview.com/ai-pilot-review/
AI Pilot Review: Key Features
✅Deploy AI expert bots in Any Niche With Just A Click
✅With one keyword, generate complete funnels, websites, landing pages, and more.
✅More than 85 AI features are included in the AI pilot.
✅No setup or configuration; use your voice (like Siri) to do whatever you want.
✅You Can Use AI Pilot To Create your version of AI Pilot And Charge People For It…
✅ZERO Manual Work With AI Pilot. Never write, Design, Or Code Again.
✅ZERO Limits On Features Or Usages
✅Use Our AI-powered Traffic To Get Hundreds Of Customers
✅No Complicated Setup: Get Up And Running In 2 Minutes
✅99.99% Up-Time Guaranteed
✅30 Days Money-Back Guarantee
✅ZERO Upfront Cost
See My Other Reviews Article:
(1) TubeTrivia AI Review: https://sumonreview.com/tubetrivia-ai-review
(2) SocioWave Review: https://sumonreview.com/sociowave-review
(3) AI Partner & Profit Review: https://sumonreview.com/ai-partner-profit-review
(4) AI Ebook Suite Review: https://sumonreview.com/ai-ebook-suite-review
Unleash Unlimited Potential with One-Time Purchase
BoxLang is more than just a language; it's a community. By choosing a Visionary License, you're not just investing in your success, you're actively contributing to the ongoing development and support of BoxLang.
Navigating the Metaverse: A Journey into Virtual Evolution"Donna Lenk
Join us for an exploration of the Metaverse's evolution, where innovation meets imagination. Discover new dimensions of virtual events, engage with thought-provoking discussions, and witness the transformative power of digital realms."
Enhancing Research Orchestration Capabilities at ORNL.pdfGlobus
Cross-facility research orchestration comes with ever-changing constraints regarding the availability and suitability of various compute and data resources. In short, a flexible data and processing fabric is needed to enable the dynamic redirection of data and compute tasks throughout the lifecycle of an experiment. In this talk, we illustrate how we easily leveraged Globus services to instrument the ACE research testbed at the Oak Ridge Leadership Computing Facility with flexible data and task orchestration capabilities.
Software Engineering, Software Consulting, Tech Lead, Spring Boot, Spring Cloud, Spring Core, Spring JDBC, Spring Transaction, Spring MVC, OpenShift Cloud Platform, Kafka, REST, SOAP, LLD & HLD.
Gamify Your Mind; The Secret Sauce to Delivering Success, Continuously Improv...Shahin Sheidaei
Games are powerful teaching tools, fostering hands-on engagement and fun. But they require careful consideration to succeed. Join me to explore factors in running and selecting games, ensuring they serve as effective teaching tools. Learn to maintain focus on learning objectives while playing, and how to measure the ROI of gaming in education. Discover strategies for pitching gaming to leadership. This session offers insights, tips, and examples for coaches, team leads, and enterprise leaders seeking to teach from simple to complex concepts.
How to Position Your Globus Data Portal for Success Ten Good PracticesGlobus
Science gateways allow science and engineering communities to access shared data, software, computing services, and instruments. Science gateways have gained a lot of traction in the last twenty years, as evidenced by projects such as the Science Gateways Community Institute (SGCI) and the Center of Excellence on Science Gateways (SGX3) in the US, The Australian Research Data Commons (ARDC) and its platforms in Australia, and the projects around Virtual Research Environments in Europe. A few mature frameworks have evolved with their different strengths and foci and have been taken up by a larger community such as the Globus Data Portal, Hubzero, Tapis, and Galaxy. However, even when gateways are built on successful frameworks, they continue to face the challenges of ongoing maintenance costs and how to meet the ever-expanding needs of the community they serve with enhanced features. It is not uncommon that gateways with compelling use cases are nonetheless unable to get past the prototype phase and become a full production service, or if they do, they don't survive more than a couple of years. While there is no guaranteed pathway to success, it seems likely that for any gateway there is a need for a strong community and/or solid funding streams to create and sustain its success. With over twenty years of examples to draw from, this presentation goes into detail for ten factors common to successful and enduring gateways that effectively serve as best practices for any new or developing gateway.
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...Juraj Vysvader
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I didn't get rich from it but it did have 63K downloads (powered possible tens of thousands of websites).
Graspan: A Big Data System for Big Code AnalysisAftab Hussain
We built a disk-based parallel graph system, Graspan, that uses a novel edge-pair centric computation model to compute dynamic transitive closures on very large program graphs.
We implement context-sensitive pointer/alias and dataflow analyses on Graspan. An evaluation of these analyses on large codebases such as Linux shows that their Graspan implementations scale to millions of lines of code and are much simpler than their original implementations.
These analyses were used to augment the existing checkers; these augmented checkers found 132 new NULL pointer bugs and 1308 unnecessary NULL tests in Linux 4.4.0-rc5, PostgreSQL 8.3.9, and Apache httpd 2.2.18.
- Accepted in ASPLOS ‘17, Xi’an, China.
- Featured in the tutorial, Systemized Program Analyses: A Big Data Perspective on Static Analysis Scalability, ASPLOS ‘17.
- Invited for presentation at SoCal PLS ‘16.
- Invited for poster presentation at PLDI SRC ‘16.
Listen to the keynote address and hear about the latest developments from Rachana Ananthakrishnan and Ian Foster who review the updates to the Globus Platform and Service, and the relevance of Globus to the scientific community as an automation platform to accelerate scientific discovery.
35. Mobile screen readers
Explore by touch
• Place finger on screen and move
• Items under your finger are
described by screen reader
• Tap with a second finger or
double tap to open/activate
36. Mobile screen readers
Gesture navigation
• Swipe right/left moves focus to
next/previous content in sequence
• Items are described by screen
reader as focus moves
• Double tap to activate
50. Native mobile accessibility
1. Mobile accessibility is different to the Web
2. Compliance is fragile
3. Testing has some subtle issues to look out for
52. Copyright 2020 Jon Gibbins, Dotjay Ltd.
All rights reserved.
Photo credits: Unsplash
Editor's Notes
Hello!
My name is Jon.
I’m an accessibility consultant.
And I’ve been working on accessibility in native mobile apps for the past 8 years.
Today I’m going to take you through:
What does it mean to be accessible on mobile?
What does compliance look like?
How do we test for compliance of mobile apps?
There are lots of links to references and resources in the presentation notes, which will be made available online later.
So don’t worry too much if you miss something I say.
What does it mean to be accessible on mobile?
On the Web we have technologies like ARIA, which allows us to create web applications that are experienced by disabled people in the same way that they would expect a desktop application to work.
On mobile devices, we have smaller screens.
We are often talking about touch screen devices.
We are working in changing environments, rather than being sat still at a computer.
One of the main issues we have with native platforms is that there are platform-specific contexts and therefore different user expectations to the Web.
For example:
There are differences in keyboard behaviour, and with what we might call focus order. For example, back buttons receive focus on iOS, but they do not on Android because there is expected to be a software back button provided by the Android operating system, or a physical back button on the device or on an attached keyboard.
Form fields carry different expectations on different platforms, as their associated interface guidelines suggest different implementations.
Today, we’re going to focus on the most mature of the mobile platforms, Android and iOS.
And we are going to focus on native code and not hybrid apps.
Basics are the same as for web
Names – as you might expect: text labels, text alternatives for image, form labels, heading text
Roles – handled automatically provided you use the standard user interface components for the platform
States and Values – also typically handled for you
While developers have some control over accessibility information – which you need when building custom controls – a lot of it is handled automatically.
On iOS, developers are able to set their own roles and states.
While this allows greater flexibility, it can result in unexpected or less consistent accessibility experiences when we test our apps.
The most important thing to check is the accessible name.
It’s also important to note that some things we experience all the time on the Web have taken some time to gain support on mobile.
For example, headings:
= September 2012 with iOS 6.0
= August 2018 with Android 9.0
What does legal compliance look like with mobile apps?
Particularly of interest in Europe at the moment is EN 301 549, an EU digital accessibility standard.
It requires that all mobile apps in the public sector comply by June 2021.
A lot of legislation currently either quotes WCAG 2.0 conformance to Level AA or it is implied.
New versions of this EU standard have been updated to reflect the new requirements introduced by the Web Content Accessibility Guidelines version 2.1.
Now, I want to talk about WCAG 2.1.
It’s been around for a couple of years now.
The general principles and the guidelines that it outlines equally apply to native mobile apps.
But we have a problem when we try to use the success criteria to test native apps.
When we try to apply Web guidelines to native software, there are going to be issues.
Version 2 of the Web Content Accessibility Guidelines may have been designed to be applicable to all technologies, but it still uses terminology and measurements that are specific to web technology.
And it is missing platform-specific context and user expectations.
Ever since the first smart phones, WCAG and its documentation didn't map well to mobile.
So, companies like Funka and the BBC ended up creating their own mobile guidelines.
Today, despite being relatively new, WCAG 2.1 still uses terminology that doesn’t match the context of native mobile, even though there are new success criteria for touch screen and mobile devices.
Some examples:
Talk of “Web content” and "Web technologies”
Talk of "Web pages"
Talk of “CSS pixels” in success criteria thresholds.
Talk of ”content implemented using markup languages"
This should change with the next version of WCAG (Silver / AG / W(3)CAG).
The W3C's Accessibility Guidelines Working Group is working to produce a set of guidelines applicable to wider technology.
In the meantime, some success criteria can be applied to native mobile apps… [NEXT…] “in the spirit of” their intended purpose.
…in the spirit of their intended purpose.
When I’m writing accessibility audit reports for mobile, I use this phrase borrowed from Patrick H Lauke.
The tricky thing to decide here is whether or not you feel that an issue you find “in the spirit of” a WCAG success criterion is actually a failure of the guidelines, or a best practice.
This is important when it comes to the European Standard, though, because it requires conformance to WCAG as interprets the guidelines for non-web software, which includes mobile applications.
For example, page titles…
Following WCAG to the letter, 2.4.2 requires that “Web pages have titles that describe topic or purpose.”
A screen in a native mobile app is not a web page, and therefore this success criterion is not applicable.
In fact, Page Titled is not required for conformance to EN 301 549, as noted in section 11.2.4.2.
But it is possible to implement something similar as a screen title.
I flag some issues as best practices “in the spirit of” WCAG, but it is up to you to decide if it’s a best practice or a failure against the standard you are testing to.
I don’t expect you to be able to read these.
We’re going to play WCAG Bingo! and cross some of these off.
This is a list of all 78 success criteria in WCAG 2.1.
I won’t be able to cover all of these today, but I can talk about the major stumbling blocks based on my experience.
I’m going to translate some of these success criteria for use in native mobile apps and relate them to my test process.
I’m going to assume that everybody here is familiar with using WCAG 2.1 as it relates to Web content.
If we remove all AAA issues that are not required for legal compliance, we are left with 50 success criteria at Level AA.
In terms of compliance, when I’m testing against AA, I will often report AAA issues that I find as best practices.
One AAA requirement in particular comes up with native mobile apps – Target Size – which I’ll talk about more in a moment.
Some success criteria are essentially the same on mobile as on the Web.
For example, I’m not going to talk much about colour or multimedia today.
Some things to note here, however:
Non-text Content
iOS 11 introduced a feature that uses artificial intelligence to try to make sense of unlabelled user interface elements. VoiceOver will announce to users “Possible text:” and then try to describe the element. However, this is often not enough to clearly label the element.
Info and Relationships
I mentioned form fields earlier and that there are differences in the expected behaviours on native mobile apps.
It’s worth taking note of the expected behaviours in native apps bundled with the platforms – such as the settings apps – but this requirement is essentially the same as on the Web.
Consistent Navigation / Consistent Identification
Consistent Navigation and Consistent Identification are not required for conformance to EN 301 549, as noted in sections 11.3.2.3 and 11.3.2.4.
Status Messages
When a dynamic message appears, it must be announced by screen reader software.
Features exist on both platforms that allow this to happen, yet it is often missed by developers, so it is worth testing for.
Okay, let’s quickly cover a few more success criteria that are essentially not applicable to native mobile apps.
Text Spacing
While it’s possible for developers to control text spacing, this is not a user preference setting on native mobile platforms.
The situation may change in the future, however.
We can implement our own accessibility settings for this within our apps, of course. It's up to you to decide if this is a failure or best practice.
[NEXT…]
More information:
Android: android:letterSpacing (Android 5.0 Lollipop, API 21) – https://developer.android.com/reference/android/widget/TextView#attr_android:letterspacing
iOS: NSKernAttributeName (iOS 6.0+) – https://developer.apple.com/documentation/uikit/nskernattributename
Content on Hover or Focus
This tends to not happen on native mobile since people are often using a touch screen device and generally not using mouse or keyboard.
Again, this situation may change.
More on keyboard accessibility later on.
Bypass Blocks
Screen content on mobile tends to not require a way to bypass blocks because of small screens.
Navigation menus are often revealed using a button and so don't need to be bypassed.
Where navigation menus are visible – such as on larger tablet screens – the expectation is that people using a screen reader can jump to a heading at the top of the next panel of content.
People using a mobile screen reader are provided with navigation features that can help jump to different types of elements. However, such useful navigation features simply do not exist for people who rely on keyboard to navigate apps.
While screen elements can now be identified as headings on both Android and iOS, Android does not yet provide a way to navigate by heading.
More information:
Bypass Blocks is not required for conformance to EN 301 549, as noted in section 11.2.4.1.
Multiple Ways
The number of screens in mobile apps is typically small, and so I find this success criterion is difficult to apply in a useful way.
One useful example can be found in native settings apps, where a search field can be an extremely helpful alternative to navigating through menus.
Focus Visible
Android and iOS handle focus indication in native apps for you – a rectangle is shown around elements as they come into focus.
However, a common issue is experiencing elements that are not visible on screen and yet receive focus.
This causes focus indication to disappear, and it can even make focus reset back to the top of the screen.
These are the observed effects of a different problem rather than a problem of visible focus.
Language
There is currently no way to specify the language of an app in Android or iOS for accessibility purposes.
You can localise an app to different languages, but this is not the same thing as identifying the primary language for accessibility.
Screen reader software on mobile platforms use the language set in the user’s operating system settings.
Changes in language
Both VoiceOver on iOS and TalkBack on Android (since Android 8 Oreo) can detect languages and adjust their speech output as needed.
On iOS, you can control the language of individual views within an app if you need to.
On Android, you currently have no control over this.
More information:
Language of Parts is not required for conformance to EN 301 549, as noted in section 11.3.1.2.
Parsing
Since this success criterion relates to markup languages, this is not applicable at all to native apps.
More information:
While user interfaces on some platforms may be defined using XML, the creation of these files is either a transparent part of the development process, or require robust code to work with the target platforms at all, let alone any assistive technology working with those platforms.
What’s left?
I’ve found some of these require interpretation when working on native mobile platforms.
Let’s take a look through these.
Some of the remaining criteria are part of the 17 new success criteria in WCAG 2.1.
Some people are still getting used to these, so let’s quickly talk through the ones that apply to mobile.
These 8 new success criteria are very relevant to mobile:
1.3.4 Orientation (AA)
Allow screens to be used in either orientation (landscape or portrait), as some people cannot rotate their device.
I find that it is very common for native mobile apps to lock users to either landscape or portrait.
Be sure to test with orientation lock settings turned off – Auto-rotate (Android) or Orientation Lock (iOS)
2.1.4 Character Key Shortcuts (A)
Allow users to turn custom keyboard shortcuts off or change them.
Practically, this is rarely found in the wild on native mobile – mostly in games.
2.5.1 Pointer Gestures (A)
Anything you do using a gesture – essentially, anything that isn't a tap – should be possible in some other way. This may be a button, for example.
2.5.3 Pointer Cancellation (A)
Avoid touch-based functionality that users have no way to cancel.
Essentially, actions are performed on releasing your finger and not on the down press.
2.5.3 Label in Name (A)
Ensure that visible text labels are part of the accessible name used by assistive technology software.
Voice control software is used a lot more on mobile devices.
Voice software needs to be able to use the app code to identify controls that a user may trigger with their spoken commands.
So, an accessible name should not only exist, it should match any visible text labels.
2.5.4 Motion Actuation (A)
Movement of a device – such as shaking the device – must not be used as the only way of performing an action, and users should be able to turn off any such feature.
2.5.5 Target Size (AAA)
Interactive elements should measure at least 44 CSS pixels in either dimension.
This helps users to avoid accidentally pressing something they didn’t mean to.
Note the use of Web terminology here, and that it’s a Level AAA success criterion. More on this in a moment.
Incidentally, it looks like the next version of WCAG will bring a new success criterion related to this requiring suitable spacing between target areas (Pointer Target Spacing).
2.5.6 Concurrent Input Mechanisms (AAA)
Allow people to use the input devices that suits them best. Don’t assume what that may be and disable something that someone may rely on.
This is most easily tested by experience – using accessibility features to check that nothing has been disabled.
The others also important for mobile are:
1.3.5 Identify Input Purpose (AA)
People with mobility issues have difficulty entering data into the fields.
People with cognitive disabilities may have difficulty remembering details.
Support for tools that can help with this is still in its early days on mobile.
But some of the code features required to make this a reality are already available in Android and iOS.
This success criterion is often ignored in mobile accessibility audits because it does not match up with the standard HTML5 autocomplete values.
1.4.10 Reflow (AA)
When we change device orientation, we expect content on screens of our mobile apps to visually reflow without loss of content.
Most of the time I find apps reflow with no issues.
However, problems do arise when we test for resizing text. More about that later.
Now that we’ve reviewed the new WCAG 2.1 success criteria, we have a small number left to discuss.
These can be covered off by telling you a bit more about my test process, so let’s do that…
Analysing code requires access to code, of course.
This is something your development team can do to test as they build.
For iOS apps:
Xcode doesn’t really have an accessibility linting tool as such, but does have different tools that we will talk about in a moment.
For Android apps… [NEXT…]
Android Studio has a linting tool that gives warnings about accessibility issues.
This slide shows the Lint tool displaying some accessibility issues in an app.
[NEXT…]
More information:
Found under *Android > Lint > Accessibility*
https://developer.android.com/guide/topics/ui/accessibility/testing#lint
Generally speaking, it’s estimated that around 30% of the Web Content Accessibility Guidelines can be tested using automated tools.
We may be talking about native apps here, but the situation is much the same.
And as with any automated testing tools, they can falsely report issues.
Several automated testing tools exist for checking your Android and iOS apps.
Google provides Accessibility Scanner for Android.
Apple provides Accessibility Inspector for iOS.
Both of these detect accessibility issues on your screens then suggests how to fix them.
[NEXT…]
More information:
Android
Download Accessibility Scanner – https://g.co/accessibilityscanner
Get started with Accessibility Scanner – https://support.google.com/accessibility/android/answer/6376570
Info on reading Accessibility Scanner results – https://support.google.com/accessibility/android/answer/6376559
iOS
Accessibility Inspector is built into Xcode
Xcode > Open Developer Tool > Accessibility Inspector (or stand alone)
Accessibility Scanner runs on your Android device.
It must first be downloaded to your device, then enabled in Android’s accessibility settings.
This adds a floating button on your screen that is used to start the scanner.
You then open your app for testing, and activate the scanner.
It detects issues on a screen or a series of screens in your app, and suggests how to fix those issues.
Full list of checks in Accessibility Scanner:
Item label missing (accessible element names)
Item labelled with type or state
Duplicate item descriptions
Editable item label
Touch target size
Resizable text
Text and image contrast
Clickable links
Duplicate clickable views
More information:
Note: If you distribute your app on Google Play, you have access to a pre-launch report for your app, which includes the results of accessibility tests using the same engine used for Accessibility Scanner.
Accessibility Inspector comes with the iOS development environment, Xcode, and it runs on your Mac.
As its name suggests, it allows you to inspect your iOS app’s interface elements for accessibility information.
This works with the Simulator on your Mac or with an attached iOS device to test any app on that device (requires an Apple Developer Program license).
It has an audit feature, that will scan for common accessibility issues and suggest how to fix them.
It also allows you to manually check support for the iOS accessibility preference settings, such as Increase Contrast, Reduce Motion, etc.
Full list of checks in Accessibility Inspector:
Accessibility labels (accessible element names, “Element has no description”)
Missing accessibility information (usually custom interfaces, “Potentially inaccessible element”)
Something to note here: Inspector unhelpfully describes missing accessibility information in custom interfaces as “Potentially inaccessible element”
Image has no label
Image name used in description
Colour contrast
Touch target sizes
Dynamic Text support (resizable text)
It’s when I run these automated tools that I find most issues with touch target sizes:
As I said earlier, this is a best practice as a Level AAA success criterion and is not required for conformance.
Research shows that the minimum touch target size for any element is 7mm x 7mm. Anything smaller than this size makes it difficult for users to hit the element using a fingertip, but especially difficult for those with less touch dexterity.
WCAG 2.1 requires a minimum of “44 CSS pixels”.
On Android, this can be interpreted as a minimum of 44 density-independent pixels.
On iOS, this can be interpreted as a minimum of 44 points.
However, Google recommend meeting a minimum touch target of 48 density-independent pixels in Android apps, which is approximately 9mm on many screens, but this does ensure that targets are never smaller than 7mm regardless of screen size.
Accessibility Scanner flags any touch dimension that is less than the recommended 48dp.
More information:
Target Size is not required for conformance to EN 301 549, as it is a WCAG 2.1 Level AAA success criterion.
It’s worth noting that there are other automated tools that are best used as part of your continuous integration toolkit.
These help to stop changes to your apps from breaking basic accessibility over time.
And it helps keep your teams on the lookout for accessibility as they work.
The tools listed here are worth taking a look at.
[NEXT…]
More information:
GTXiLib is Google’s open source toolbox for Accessibility for iOS, test logic for detecting common accessibility issues that works with unit testing frameworks.
Google's Accessibility Scanner for iOS (GSCXScanner), uses GTXiLib.
Deque’s axe™ DevTools (formerly WorldSpace Attest), available for both Android and iOS, is a framework you incorporate into your app code that helps detect and inspect for some common accessibility issues.
https://www.deque.com/android-accessibility/
https://www.deque.com/ios-accessibility/
It’s important to test the actual user experience for people using screen reader software.
This will often uncover many of the technical issues that automated tools do not.
On Android we have TalkBack, also known as Android Accessibility Suite.
On iOS, we have VoiceOver.
Both are powerful, yet fairly easy to learn to use.
[NEXT…]
More information – common issues we may find while using a screen reader:
Controls with no accessible name
Custom interfaces missing accessibility information or behaving in unexpected ways
Missing roles, where people using screen readers will not know how to interact with a control or how it will behave
Incorrect roles – I’ve seen text fields used to display body text
Hidden elements experienced
Visible elements not experienced
Changes of state not experienced
Poor support for text resizing
There are 2 main interaction methods used by both Android and iOS.
The first method is “explore by touch”:
You place your finger on the screen and move it around
Items under your finger are described by the screen reader
You double tap to activate items, or you can tap with a second finger as well
This interaction is spatial – it requires users to become aware of the layout of a screen
This is the best way to interact with on-screen keyboards – it’s a bit like touch typing
Gesture navigation:
It’s sequential, typically following the reading order of a screen
Users interact with one element of a screen at a time
Users swipe right to move a virtual focus cursor forwards through content, and swipe left to move backwards
You double tap to activate items
An important thing to note on native mobile, is that you can detect the presence of an assistive technology, something we can't do on websites.
We can argue, in fact, that we should not detect a person's assistive technology.
Something that detection can be helpful for, though, is for stopping auto-playing any audio or video content.
On iOS, app developers also have the option of checking isVideoAutoplayEnabled.
Page Titled
This is often missed by mobile accessibility audits.
I test for this, but you may decide it is not needed.
Let me explain…
It's not well documented for Android or iOS, but it is possible to add titles to screens of native mobile apps.
On iOS, it's of less practical use, but you can add what's called a Summary Element trait.
However, it doesn't give the same behaviour as the page title on a web page.
Summary Element is only announced by VoiceOver on application load.
It is meant to explain the current state of an application.
For a weather app, for example, this may be a summary of the current weather conditions.
On Android, we have activity titles, which can be updated dynamically as different screens load.
You can mimic the experience of a web page title being announced by screen readers, but the question then becomes, should you do that when it’s not expected behaviour?
[NEXT…]
More information:
Page Titled is not required for conformance to EN 301 549, as noted in section 11.2.4.2.
I want to talk about keyboard control and how this differs from controlling a screen reader on mobile devices.
Keyboard accessibility is where we typically look at focus order and visible focus styles on the Web, as well as focusable state and focus management.
While focus on mobile devices is similar to that on the Web, there are differences.
There are two concepts of focus to understand on mobile devices: input focus and the virtual cursor.
Input focus is like keyboard focus on the Web – interactive elements receiving focus in a sequence.
The virtual cursor – or as I sometimes call it, accessibility focus – is where all accessible elements are experienced and read in a sequence by mobile accessibility features.
But let’s talk about true keyboard accessibility on mobile…
While users do not typically interact with mobile devices using a mouse or keyboard, people may be using a directional controller or connected Bluetooth keyboard.
On Android, links, fields, buttons and other controls in the content can be accessed using a keyboard in a sequence.
Android also provides support for directional controllers – such as a D-pad – which can be described as input focus.
However, the directional focus orders (up, down, left right) can be set independently of the linear focus order of keyboard navigation using the Tab key.
It is possible to support hardware keyboard control in iOS apps.
However, true native keyboard accessibility in the way we think of it on the Web hasn’t existed in iOS without using VoiceOver.
Earlier this year, iPadOS brought support for keyboard.
Users can navigate using arrow keys and activate items with the space bar.
Typically, focus order in native mobile applications is automatically determined based on the layout of controls and views.
Focus order runs from the top-left to the bottom-right of each view, unless a custom order is defined in the code.
Manually check keyboard accessibility using a Bluetooth keyboard attached to a device and navigating through screen content using the Tab key or arrow keys.
[NEXT…]
More information:
Developers can hook into key pressed on hardware keyboards from iPadOS 14.
While there are a small set of keyboard only commands, accessible keyboard navigation and control is tied to using VoiceOver and therefore there is only accessibility focus and no true keyboard focus.
Focus management
Generally, moving focus on behalf of the user should be avoided. However, it may be necessary to manage focus on behalf of the user in specific situations.
When moving from one screen to another, initial focus is usually set automatically by the operating system. If this is not the case, an expected initial focus should be set.
There are other situations when focus may need to be managed. Just as on the Web, when moving to a modal view, focus is expected to remain within that view. When a modal closes, focus typically returns to the location that triggered the modal.
https://developer.apple.com/videos/play/wwdc2020/10109/
https://developer.apple.com/documentation/uikit/keyboards_and_input/adding_hardware_keyboard_support_to_your_app
https://developer.apple.com/documentation/uikit/mac_catalyst/handling_key_presses_made_on_a_physical_keyboard
Testing with voice commands
On Android, we have Voice Access.
On iOS, Voice Control.
On Android, speech input is provided through Google's "Voice Access" application, which is enabled in *Settings > Accessibility > Voice Access*.
Voice Access is then activated by saying "Hey Google".
You need to check that all controls on the screen respond to voice commands.
Voice Access visibly labels all interactive elements with a number.
Each numbered item should activate when you give the command "Tap ITEM NUMBER".
On iOS, Voice Control can be enabled in *Settings > Accessibility > Voice Control*.
You can also enable it by saying "Hey Siri, turn on Voice Control".
Voice Control can display item names (labels) by saying "Show names".
All interactive elements should then be visibly labelled with a name.
Each named item should activate when you give the command "Tap ITEM NAME".
Voice Control can also display a grid navigation tool by saying "Show grid".
You then select the item you want to activate by saying the grid numbers until the required item is selected.
Again, check that all controls on the screen respond to these voice commands.
Most modern websites have responsive designs that adapt and reflow well to fit small screens.
While it is common to find that content in native apps reflows well with different screen sizes or device orientation, adaptability to text size is often forgotten.
WCAG requires us to test at a text size of 200%.
There is currently no way to set text to 200% on Android or iOS, but I test using the closest setting.
On Android this means “Largest setting” = approx. 132% (the largest possible)
On iOS, this means stop 10 with Accessibility Sizes enabled = approx. 235%
Note on iOS:
Stop 9 / 2nd accessibility size = 46.5px = 193.75%
Stop 10 / 3rd accessibility size = 56.5px = 235.4%
So I say that Stop 9 at 193.75% is good, but Stop 10 is needed for WCAG 2.1 compliance.
But be careful!
Not all items resize on Android and iOS.
For example, on iOS text labels in the bottom Tab Bar do not resize with increasing text size settings.
This is because of restricted space in the interface.
It is deliberate behaviour, meaning it is expected behaviour for experienced users.
Instead, users are shown a large preview of the tab item when they hold their finger over them.
[NEXT…]
More information:
When "Larger Accessibility Sizes" is enabled in the Larger Text settings and an accessibility size is then selected, a large preview of the tab label appears in the middle of the screen when users press and hold their finger over (long press) the Tab Bar items.
A similar thing happens for Segmented Controls on iOS – a drop down appears.
On Android, however, text labels in a bottom navigation bar do resize with increasing font size settings.
The two screenshots here show what can happen to text labels as space on the screen gets reduced – the text starts to get cut off.
In contrast, title text in top app bars on Android do not resize with increasing font size settings.
Again, this is deliberate because of restricted space in the interface.
Lastly, it’s helpful to take screenshots as you test a native mobile app. I take screenshots all the time as I audit.
This is usually done with some combination of the hardware volume buttons and the power button or Home button.
Automated scans may find some colour contrast issues, but not all.
Having screenshots lets me manually check for colour contrast issues with text and images.
What does it mean to be accessible on mobile?
Mobile accessibility is different to the Web, and it’s important to understand the differences.
What does compliance look like?
Compliance is currently quite fragile, because the guidelines and standards don’t match the context of native mobile platforms.
How do we test for compliance of mobile apps?
Testing has some subtle issues to look out for. I hope that this talk will help you with navigating these issues.
Thanks for listening to me, Funka Accessibility Days.
It’s time to take some questions.