Applying EU regulation to native mobile apps
Rachel Paul, IAAP: Hello everyone, thank you for joining us, I am Rachel Paul with I wi fi and before we start today's program and just have a few items to go over. Rachel Paul, IAAP: We do have closed captioning provided you can select a closed captioning icon on the bottom of your zoom screen. Rachel Paul, IAAP: And we will be providing stream tech links and German, French, Spanish and Swedish and we'll have those posted in the chat momentarily. Rachel Paul, IAAP: We also are happy today to have a check interpreters, that will be translating live, and you can select the interpretation icon at the bottom of your zoom screen and then select the check channel to hear those.
Rachel Paul, IAAP: Live translations, we do have attendee microphones muted, to prevent any background noise or disruptions. Rachel Paul, IAAP: And today's program will be recorded and made available on the I deployed to YouTube channels and we'll share that link out after the event. Rachel Paul, IAAP: We will be monitoring the chat for any general dialogue and technical issues, and we encourage you to post your questions in chat. Rachel Paul, IAAP: or i'm sorry post your questions in the Q amp a today and we will get to those as time permits and we have with us today Susanna lauren will be our host and and and we have john Gibbons with us i'm happy to turn today's program over to Susanna. Susanna Laurin: Thank you Rachel and welcome everyone, and especially welcome to all of you who were registered for this. Susanna Laurin: event when it was originally planned, we had to move it unfortunately, but now here we are finally in this.
Susanna Laurin: Beautiful winter day and we're very happy to have john with us today to teach us everything about mobile Apps and testing, but first of all, the Eurovision part of this so. Susanna Laurin: What we need from this wiki conferences civil 3D led you also need a lecture you can and does have George mason Wednesday them in chat and he gave me a link for them. Susanna Laurin: Where this Larry ellison your status and then Lastly, probably still and then you can just text them for some scam on the clickable link Can somebody get them. Susanna Laurin: And now I have to ask my dear friend radek who is volunteering, for example, at the EU to help me with the check translation of this because that I can't do.
Radek Pavlíček: Nobody done a. Radek Pavlíček: lot of us. Radek Pavlíček: grew much any additional access petition yet say activate the logical interpretation us about asking a global bit sad but, at the canal check on that slide about you know possible. Radek Pavlíček: Maybe she had room to nutrition it. Susanna Laurin: sounded. Susanna Laurin: Perfect I have no clue what you said.
Susanna Laurin: But I hope that is really helpful for everyone who can speak a beautiful and Czech language so and thank you Eric for making this happen. Susanna Laurin: simultaneous interpretation I think this is a big step for I play piano we're now moving more towards the eastern part of Europe as well, and and welcoming even more members from from other countries where English may not be the. Susanna Laurin: First language for everyone, so that is just what we are doing this is the last webinar of this. Susanna Laurin: autumn we are then going on holidays and then we get back with with more interesting webinars and the newsletter, of course, keep on doing that in the springtime and then we are planning for a face to face event. Susanna Laurin: In Brussels in during the spring so keep tracking and following us in all the channels, where we are, but now I want to.
Susanna Laurin: give the floor or give the MIC or I don't know what i'm giving to to john Gibbons who is one of the most clever people I know when it comes to. Susanna Laurin: testing of mobile Apps, which is one of the most difficult things that most men and monitoring agencies and accessibility experts are really struggling with in the year, these days, so i'm very, very happy to. Susanna Laurin: Introduce to you a person who can teach you everything, and you will be enlightened and know much more about this very interesting and. Susanna Laurin: important topic after today's webinar so john will make the presentation first and then we'll take questions afterwards so just please, please put them in the Q amp a and i'll make sure that we respond to as many as as possible from them Okay, thank you john please. Jon Gibbins: Thank you very much for the wonderful introduction and apologies that we had to delay this session law is unfortunate came down with Kobe just before the last scheduled.
Jon Gibbins: time for this event and and so i'll just share my slides a moment, so we can get started, but hello to. Jon Gibbins: Everybody who's who's joining us today, and thank you for joining us, I hope I can live up to what Susanna has said in my introduction, so yes. Jon Gibbins: Wanting to john i'm a digital accessibility consultants i've been working in the field for nearly 20 years now and i've been working on accessibility in native mobile Apps for nearly 10, though. Jon Gibbins: And over the next 3040 minutes i'm going to take you through what guidelines do we have for mobile, what does compliance look like i'm particularly talk about in 31549 and. Jon Gibbins: How do we test for compliance of mobile Apps there are lots of links to references and resources in the presentation notes, which are make the slides available.
Jon Gibbins: So don't worry too much if you miss something of course it's being recorded as well if we get time of perhaps DEMO some of the testing tools that I talked about, but I have a couple of screen casts to some videos to show you of those things so let's let's make a start. Jon Gibbins: So guidelines and standards, what do we have when it comes to mobile guidelines well many people watching will be aware of the web content accessibility guidelines, the current recommendation 2.1 version 2.1 published in June of 2018. Jon Gibbins: version 2.2 is on its way do in the next month or two, with some additions that are relevant to mobile I will discuss these and how they impact on standards like em three or one by following but won't be going into too much detail about those. Jon Gibbins: Some of the wcc documentation it relates to web much more than mobile So what has happened over the years is we've had other. Jon Gibbins: Mobile accessibility guidelines Franco being one of the very first to produce a set of mobile accessibility guidelines for for use with with native mobile devices, based on the web content accessibility guidelines, the BBC have also published some. Jon Gibbins: Mobile accessibility guidelines published back in 2014 including what was missing at the time, so a lot of.
Jon Gibbins: techniques for using html in mobile Web. Jon Gibbins: Some code to be used on android and ios but it's in need of updating, which I understand is happening soon. Jon Gibbins: New new technologies caitlyn instead of Java on android swift and swift ui instead of objective C or on ios these code examples need updating and, of course, every year.
Jon Gibbins: ios and android have a new release new api's new functionality, the weekend us to make our Apps more accessible, so we need to keep these guidelines and resources up to date. Jon Gibbins: ios have their human interface guidelines which have some items around accessibility. Jon Gibbins: been recently reading very much clearer some unfortunately poor recommendations from an accessibility point of. Jon Gibbins: view.
Jon Gibbins: In my opinion, in their things like recommending placeholder text as form labels which. Jon Gibbins: may understand from web accessibility is not ideal and it's not ideal on ios and android either so. Jon Gibbins: there's some items in there, that I would disagree with from an accessibility point of view and Google and material design have their own set of accessibility. Jon Gibbins: Guidelines and, as I say, there are links to these resources in the slide notes and there are some further platform specific guidelines available in the resources at the end of this deck of slides as well, these are kind of the main ones that we. Jon Gibbins: update our talk more about some of the standards as well, so what does compliance look like well I generally avoid talking about legislation, but what I want to touch on is. Jon Gibbins: Is legal compliance and what it looks like for mobile Apps so a lot of the law around the world, currently either quotes web content accessibility guidelines Level two.
Jon Gibbins: version two conformance at Level double a or it's implied, so what keg, as we call it is a logical starting point when working with accessibility for mobile Apps. Jon Gibbins: Although I don't know many that specifically mentioned mobile Apps but rather mentioned electronic content or software in general. Jon Gibbins: And one in particular that stands out here is in Europe, we have in three 1.49 and that specifically mentions mobile Apps and requires or mobile Apps in the public sector to comply by June of this year, so we're now past that deadline. Jon Gibbins: and new versions of the standard have been updated to reflect the new requirements introduced by a keg so let's let's talk about that for a moment. Jon Gibbins: So this harmonized standard it's been designed to be compatible with other accessibility standards and regulations, while covering all digital technology, not just web and mobile Apps are covered by. Sam Evans IAAP/G3ict: Meeting.
Sam Evans IAAP/G3ict: Sorry. Jon Gibbins: Susanna thinking, he can meet. Jon Gibbins: So. Jon Gibbins: Thank you. Jon Gibbins: Mobile Apps are covered by section 11 of the standard software and talk some more about that, through through the rest of the session that.
Jon Gibbins: I should note here that i'm focused on native mobile applications here and therefore what mainly on that section and talk about remix as well, and how that can be helpful. Jon Gibbins: i'm not going to cover voice communication video web content that's contained within a native mobile APP hybrid content or digital documents that form or forms. Jon Gibbins: contained within a native mobile Apps such as PDF these are these are covered by section 679 and 10 of the legislation, and so what i'm mainly focusing on here is how we apply. Jon Gibbins: The web content accessibility guidelines as a framework through in 31549 to make our perhaps more accessible. Jon Gibbins: Now there's a lot of things I could talk about in there, I could cover in this session, and it would go way over the time so I needed to find a way to boil that down, so I. Jon Gibbins: come up with a way of going through most things that all the things that are any particular interpretation.
Jon Gibbins: When working with mobile so forgive me for not going through absolutely everything it just simply isn't the time to go through everything but. Jon Gibbins: If you've already got an awareness of the web content accessibility guidelines, then you should be able to understand the things i'm going to talk about so. Jon Gibbins: In 2018 the the the entry or 1549 standard was updated to specifically include mobile Apps and reflect work ag 2.1 conforming it level double a. Jon Gibbins: And the most recent versions include further resources, including a table of minimum requirements for mobile Apps in Annex A, which also serves as a helpful checklist, if you like, for conformance for mobile Apps and it's one of the few checklists I know for mobile Apps another. Jon Gibbins: Google have their own developer checklists to.
Jon Gibbins: Show accessibility of android Apps. Jon Gibbins: So let's talk a little about the web content accessibility guidelines it's been around for this this version 2.1 has been around for a couple of years. Jon Gibbins: And the general principles and guidelines that it outlines equally apply to native mobile Apps, but we have a problem when we try to use the success criteria in will tag to test and making native Apps conformed.
Jon Gibbins: So Problem number one when we try to apply web guidelines to native software, there are bound to be issues so version two of work ag may have been designed to be applicable to technologies. Jon Gibbins: Digital technologies but it's still uses terminology and measurements for the success criteria that are specific to web technology. Jon Gibbins: And so it's missing platform specific context and user expectations. Jon Gibbins: Ever since the first smartphones were keg, and its documentation didn't map very well to mobile and this is why companies like francoeur and the BBC ended up creating their own mobile guidelines. Jon Gibbins: So, today being relatively new we're carrying 2.1 still use this terminology that doesn't match the context of native mobile. Jon Gibbins: Even though there are new success criteria for the covered touchscreen technology and mobile devices specifically let's take a look at this.
Jon Gibbins: So some examples we have talk of web content and web technologies in the success criteria talk of web pages within success criteria CSS pixels in success criteria thresholds CSS being a web specific technology, a talk of content implemented using markup languages. Jon Gibbins: This might change with the next version of working currently called silver. Jon Gibbins: The WCs accessibility guidelines working group is working to produce a set of guidelines that are applicable to wider technology in the meantime. Jon Gibbins: Some work and success criteria can be applied to native mobile as I like to say, in the spirit of their intended purpose or phrase I borrowed from Patrick a girlfriend. Jon Gibbins: When i'm writing accessibility audit reports for mobile against the web content accessibility guidelines, I will often use this phrase. Jon Gibbins: Because the tricky thing here is to decide whether or not something that is worded in a way that reflects web content is actually applicable at all to mobile.
Jon Gibbins: Apps, which is why in 31549 attempts to make translational which is great so. Jon Gibbins: The issue, there is another problem, and this is more of a personal observation that web accessibility is not the same thing as native accessibility it's not the same as software accessibility or mobile accessibility, this is why we need to have these interpretations. Jon Gibbins: And we talk a lot about web accessibility and that's no surprise, really, we have the web content accessibility guidelines, the most widely accepted accessibility guide guidelines for digital products. Jon Gibbins: which was developed by the World Wide Web consortium, who are focused on the web, they do great work.
Jon Gibbins: But they're the International Standards Organization for the World Wide Web and develop web standards not digital standards. Jon Gibbins: Of course, as I said, changes are coming in that respect, perhaps we need to be starting talking more and more about digital accessibility. Jon Gibbins: to encompass and include websites mobile and other digital presentations and embrace that wider context of the work we do in this field. Jon Gibbins: But, for me, this is why one reason that potentially the web content accessibility guidelines and its derivatives standards. Jon Gibbins: don't translate well for working in the specific contacts of native mobile platforms like ios and android by abstracting the work tag success criteria.
Jon Gibbins: To apply to software in general, rather than to be understood within the specifics of a platform like ios and android its nuances. Jon Gibbins: Its capabilities its user expectations we end up with with problems so on one side, we have the problem that legislation cannot be too specific, so we end up with. Jon Gibbins: Legislation that covers software in general, on the other hand, we to being too broad risks being too prescriptive or vague when it comes to applying those principles and success criteria to. Jon Gibbins: To specific platforms in a meaningful way. Jon Gibbins: So it becomes about translating standards for specific contexts, and this is why we need to have new resources that translate the great work of the web content accessibility guidelines and entry or 154 line.
Jon Gibbins: To make sense within these contexts and to be narrower, in application than the broader context of software in general. Jon Gibbins: So the accessibility guidelines that we use need to acknowledge these different behaviors but perhaps them what we need is additional documentation like. Jon Gibbins: We have the wi aria offering practices they exist to translate the expectations of desktop applications and widgets into working in the context of the web. Jon Gibbins: We need the same kind of translations for platforms like ios and android and there are people doing great work in this area rob whitaker. Jon Gibbins: written a book on mobile accessibility and has mobile 811 y.com with some great information on ios and android a ppt.nl are working on. Jon Gibbins: Mobile specific translation of the web content accessibility guidelines for ios developers and android developers.
Jon Gibbins: To, how do we interpret that and working on interpreting those guidelines for the specific platforms and I started developing self on github as well with some resources for android and ios around these ideas. Jon Gibbins: Okay, so let's do a bit of translating now first I must say this is very small text I don't expect you to be able to read these. Jon Gibbins: i'll just tell you what's going on here, so this is a list of all 78 success criteria currently in web content accessibility guidelines 2.1. Jon Gibbins: I won't be able to cover all of these today, but I can talk about the major stumbling blocks, based on my experience. Jon Gibbins: i'm going to translate some of the success criteria for use in native mobile Apps and relate them to my test process. Jon Gibbins: i'm going to assume that everybody is familiar with working 2.1 as it relates to web content So what can we do here first thing we can do.
Jon Gibbins: Is we can remove all the triple pay issues that are not required for legal compliance, we are left with 50 success criteria level double a so sometimes I will test for some AAA issues and I will mark them as best practices i'll talk more about those in a moment. Jon Gibbins: One in particular target size of i'll talk about let's remove some more move another another group. Jon Gibbins: Some success criteria are essentially the same on mobile, as they are the Web so there's not much point in me talking about these, for example, i'm not going to talk too much about color or multimedia video today.
Jon Gibbins: But I will talk about some of these others. Jon Gibbins: I can remove. Jon Gibbins: text spacing. Jon Gibbins: So we can remove that because at the moment it's not possible for developers to control tech spacing. Jon Gibbins: Sorry, it is possible for developers to control text based it's not possible for users to set their own user preferences and this, which is what the success criteria criterion relates to. Jon Gibbins: So I.
Jon Gibbins: Generally don't test for that one at this time. Jon Gibbins: Of course we can implement such user preferences within our own APP it's not available, the operating system level, so we can test for them, and failed them if we wish so but that's the level at which we would need to implement that. Jon Gibbins: content on hover or focus well this tends not to happen or content on overall focus tends not to happen on native mobile, for the very reason that it's a touchscreen device, so we don't really hover on things, we have a lower press. Jon Gibbins: We don't really focus on things because we're not generally not using a keyboard with these devices, although that is changing more on keyboard accessibility later so generally, this is one that doesn't apply in the current the current time.
Jon Gibbins: bypass blocks, we tend to be working with much smaller screens over we have tablets screens that are getting larger and larger. Jon Gibbins: Net, so this can be applied in some ways, navigation menus are often revealed using a button, so they. Jon Gibbins: don't need to be bypassed necessarily But then when we're working the context when we're working with keyboard there is increasingly changes to how native Apps work again i'll talk more about that later about keyboard. Jon Gibbins: But there are ways that the operating systems themselves are aiding providing aids for users, using keyboard to bypass blocks, without the need for APP developers to implement these so I currently don't test for this one very much unless I noticed an issue. Jon Gibbins: But it is applicable it's just that.
Jon Gibbins: Currently, either there hasn't been away for developers to. Jon Gibbins: implement a solution or the solutions are now currently being implemented it an operating system level so developers don't need nothing. Jon Gibbins: So there are some some uses here there's more notes in the. Jon Gibbins: In the in the slide deck and one thing to note here is that a bypass blocks is not required for the components of the entry one by four nine so. Jon Gibbins: There are some some some things to keep in mind there when working with particular standards.
Jon Gibbins: So multiple ways, the number of screens in mobile Apps is typically small. Jon Gibbins: And so I find this success criteria and difficult to apply in a useful way one one example, can be found in the settings Apps of ios and android. Jon Gibbins: Where there's a search field that can be extremely helpful alternative to navigating through the menus, especially when apple or Google have moved, one of the one of the settings that. Jon Gibbins: One area of the settings APP to another so search can be considered a different way to accessing the content in that APP rather than navigating through multiple menus but generally multiple ways is not something that can be usefully applied to native mobile Apps again, this may change. Jon Gibbins: Focus visible generally ios and android android handle focus indication in Apps for you. Jon Gibbins: Common issue is experiencing elements that are not visible on the screen, but they do receive focus, which causes multiple multitude of problems.
Jon Gibbins: or different types of problems but generally, the problems are the effects of a different problem so then visible focus That said, there are ways to change the focus styles of. Jon Gibbins: Apps. Jon Gibbins: User interface elements in ios and android when using keyboard, but when using other technology generally, the focus is. Jon Gibbins: is something that's handled for you. Jon Gibbins: Language there's currently no way to specify the language of an APP in ios or android, at least not for accessibility purposes, you localize an APP to different languages.
Jon Gibbins: But this is not the same thing as identifying the main language for accessibility so screen reader software on mobile platforms use the language that is set in the user's settings. Jon Gibbins: Something we can do is. Jon Gibbins: identify changes in language within an APP So if you have an English APP and then you have a part of the APP is is written in French, we can say okay this part is in French and then that will cause the screen reader to use the correct speech output. Jon Gibbins: So in ios you can control the language of individual views within your APP where you need to currently there is no way to do so on android. Jon Gibbins: So this covers language of pants on on the web content accessibility guidelines but note that language of parts is not required for conformance in 3215 or nine. Jon Gibbins: last one.
Jon Gibbins: Passing Now this is specifically related to markup languages so it's not applicable the tool to native Apps. Jon Gibbins: While user interfaces on on the platforms are defined using a markup language xml generally the Apps won't work if this is not. Jon Gibbins: well structured so that this tend to be something that is just not applicable to native so what what do we have left. Jon Gibbins: So these are the items that we have left and I found that some of these require interpretation when we're working on native mobile so some of the remaining criteria part of the 17 new success criteria.
Jon Gibbins: Then what happened there a PowerPoint has crashed. Jon Gibbins: So, while I bring my slides back up and reshare them. Jon Gibbins: Some of these these success criteria that we're going to work through relate to the new newer web content accessibility guidelines 2.1. Jon Gibbins: requirements.
Jon Gibbins: where's my it's nice when. Jon Gibbins: So we talk through some of those and then we'll talk about some of the others in the context of how I test an APP and hopefully i'll be able to demonstrate some of the tools that I use as well. Okay. Jon Gibbins: Just find the slide back up to.
Okay. Jon Gibbins: share my screen. Jon Gibbins: Okay sorry about that Okay, so we have orientation, this allows screens, to be used in either landscape or portrayed as some people can rotate their device. Jon Gibbins: And I find it very common on native Apps to lock the user to one land either landscape or portrait and generally, it should be relatively straightforward to support both orientations so.
Jon Gibbins: it's it's then it's very easy for developers, to make a change to to to turn on support for those orientations is just checking them and these days with me to adapt our. Jon Gibbins: layouts and our views on mobile Apps to apply to different screen resolutions and two different different capabilities so adjusting so that things automatically. Jon Gibbins: Change layout for different orientation should be relatively straightforward to implement, but so support for orientation. Jon Gibbins: So that can be checked by making sure the orientation lock settings are turned off on ios or android and then checking both orientations for screen. Jon Gibbins: identify input purpose people with mobility issues have difficulty in entering data into the field, sometimes people with cognitive difficulties may have difficulty remembering details. Jon Gibbins: So there are identify input purpose provide support for tools that can help with this, and still but some of the features on ios and android provide auto fail functionality for for Apps and so.
Jon Gibbins: Both on ios and android more recent versions of the platforms provide. Jon Gibbins: The values that are used in in the success criteria, the html5 autocomplete values, allowing people to allowing developers to specify whether a fear of falling field. Jon Gibbins: Has is expecting an email or the first line of somebodies address or somebody city kind of thing, so those kinds of things can be supported and can be tested for it level of life. Jon Gibbins: Another double a requirement we flow we when we change the device orientation, we would expect that the content, our screens mobile Apps visually re flow without loss of content or functionality. Jon Gibbins: And, most of the time, I find the Apps we flow, with no problem, however, problems do arise when testing for support for resize text which will come on to the moment character key shortcuts.
Jon Gibbins: This is rarely found in the world. Jon Gibbins: Sometimes in in mobile games, but the idea is to allow users to customize any keyboard shortcuts or turn them off and character key shortcuts are becoming something that. Jon Gibbins: has greater support in recent versions of ios and android so that's something to look out for. Jon Gibbins: pointed gestures anything you do, using a gesture essentially anything that isn't straightforward tap on the screen, should it should be possible to do that now. Jon Gibbins: Action in some other way, so this might be, by providing a button alternative to pull to refresh or something like that so some ios and android also provide.
Jon Gibbins: Support accessibility features to. Jon Gibbins: provide access to to gestures and for people who has can't perform justice on the screen, so there is also assistive technologies, helping at the operating system level. Jon Gibbins: On both ios and android to to solve the problem that this success criteria, aims to solve point a cancellation. Jon Gibbins: Where somebody puts an action is performed when somebody releases their finger from the screen, not when they put their finger down it helps to avoid any functionality that users have have no way to to counsel and this is something that I rarely find happens, but.
Jon Gibbins: Most of the time actions are performed on releasing some finger. Jon Gibbins: Motion activation the movement of a device, such as shaking the device must not be the only way that people have. Jon Gibbins: Access to performing an action and if users should be able to turn off any such functionalities that they don't accidentally cause.
Jon Gibbins: something to happen so an example shake it to undo and I remember some Apps have shaped to provide feedback I believe Facebook had beers or there was a MAC tap also had this. Jon Gibbins: Where i'd be out for a jog and it would be continually asking for my feedback, because I was moving the device, and I would want to turn that off, so there are. Jon Gibbins: Other reasons for having this this functionality, but just like with pointer gestures motion activations and moving a device should not be the only way that her user has access to performing connection. Jon Gibbins: Now let me reviewed those web content accessibility guidelines version 2.1 success criteria, we have a small number left to discuss and I interpret the success criteria with particular care when applying them to ios and android. Jon Gibbins: These can be covered by telling you a bit more about my test process for. Jon Gibbins: mobile devices, so this is a summary approach how I go about testing.
Jon Gibbins: Now, as an accessibility auditor it's rare for me to have access to a code base so analyzing code would be my first action. Jon Gibbins: But of course it requires access to the code, so this is something that developers can do to test as they build and for ios Apps X Code, the development, environment. Jon Gibbins: doesn't currently have an accessibility, limiting tool as such, but it does have different tools that we will talk about in a moment, but this is changing. Jon Gibbins: let's talk about what's available on android studio android studio has a linkedin tool that gives warnings about accessibility issues in your code. Jon Gibbins: So this slide shows that the lintel displaying some accessibility issues for an APP it's run from the menu analyze inspect code and then the results are shown on the android lint accessibility and you can see some examples here are some of the issues that it can find. Jon Gibbins: accessibility and custom views it means with with our content description, this is essentially a missing text alternative for an image.
Jon Gibbins: Missing accessibility label being very similar and then keyboard inaccessible widgets are these are things we should be familiar with from working with the Web web content. Jon Gibbins: Second, at all, no my automated scan so just like with the Web around a third of the web content accessibility guidelines can be tested using automated tools and comes with the same caveats so. Jon Gibbins: Was we may be talking about native Apps here this, we still have to interpret the results as they can falsely report issues so it's about understanding the results as much as getting results for accessibility issues. Jon Gibbins: And several automated testing tools exist, Google provides accessibility scanner for android apple provides accessibility inspector for ios and comes with xcode. Jon Gibbins: Both of these detect accessibility issues on your screens and then suggests how to fix them. Jon Gibbins: So accessibility scanner it's an APP that you download your android device you enable it in accessibility settings and it adds a floating action button to your screen.
Jon Gibbins: That you use to start the scanner and it will find issues like missing text alternatives missing labels issues with touch target size, lack of support for resizing text and color contrast issues, and so we go to accessibility, we turn on the accessibility scanner. Jon Gibbins: And then we go to an APP that we want to test. Jon Gibbins: We activate the scanner we can do it in record or snapshots that snapshot snapshot will just take one screen and record will go through a user journey and take multiple screenshots. Jon Gibbins: And then it produces a report So here we have a report, but this item and another item has poor touch target size and tells you the dimensions of those things and provides information on how to how to fix those things.
Jon Gibbins: Accessibility inspector comes with the ios development environment xcode and it runs on your MAC. Jon Gibbins: as its name suggests, it allows you to inspect your ios Apps interface for accessibility information, and this will work with the simulator on your MAC or with an attached ios device to test any APP on that device. Jon Gibbins: So, how does it work well, it can check for very similar issues to. Jon Gibbins: The accessibility scan on android missing accessibility labels or other information like state information touch target sizes, support for dynamic type result resize text and color contrast. Jon Gibbins: So once we've got the device setup we can inspect items on the device, so this is my my device plugged into my mind map. Jon Gibbins: And i've tapped on i've hit inspect and then tax on an item and it tells me information about that item.
Jon Gibbins: And then I can navigate through using these arrow buttons to navigate to other items and find out information about that and check the order of content. Jon Gibbins: I can also run an audit, which, just like accessibility scanner produces a list of items and provides idea of how to fix those items, it also has support to check the display accommodation so customizations that users can make change a support for changing in techstars support for. Jon Gibbins: Reduced motion settings for bold font and to make things better, and we see things change as I select things on and off here, increasing contrast contrast changes on the APP these are things that should be supported. Jon Gibbins: Now some of these items go beyond the scope of the web content accessibility guidelines and the regulation, but things like. Jon Gibbins: resizing text should be tested and that can all be done or some of those things can be done using this tool, and it can also be used to.
Jon Gibbins: This is inspecting the simulator So if you do have access to the coding run the simulator or MAC you can also use the same tool to check accessibility in that. Jon Gibbins: So this is a good place to talk about target size. Jon Gibbins: it's when I run these sorts of automated tools, I find most issues around touch target sizes, as I said, this is best practice as a level triple eight success criteria will take 2.1.
Jon Gibbins: And there's not currently required the conformance so research shows that you are the tips of our fingers are around seven millimeters by seven millimeters and we translate that. Jon Gibbins: for use in native mobile now the web content accessibility guidelines say 44 CSS pixels what does that mean well they're essentially relative units and we have relative units on ios android. Jon Gibbins: On android this can be interpreted as meaning 44 density independent pixels or DPS on ios this can be interpreted as 44 points one note here is that Google recommend a minimum touch target size of 48 DPS which relates to kids it's grid unit of ATP. Jon Gibbins: So when you're running accessibility scanner it will flag up any issue that any touch dimension that is less than the 48 db rather than 44 to bear in mind that's a difference in conformance level as well. Jon Gibbins: So no it's not required for conformance two and 315 for logging, but can 2.2 that's coming soon will update the level double a success criteria so look out for that, however. Jon Gibbins: Note that in 32154 line is unlikely to get updated from what can 2.1 success criteria, at least not anytime soon, and I do have information about the requirements around to have that 2.2 will bring if you're if anybody's interested.
Jon Gibbins: There are other automated tools, these are mostly for integrating with automated integrating with the development toolkit so these help to stop changes in Apps from breaking accessibility over time and it helps keeps development teams on the lookout for accessibility, as they work. Jon Gibbins: screen readers it's important to test the actual user experience for people using screen readers software, so this will uncover many of the technical issues, the automated tools do not on android we have talkback, also known as part of the accessibility android accessibility sweet. Jon Gibbins: On ios we have voiceover so we talked back and voiceover and both are powerful yet easy to learn to use compared to a desktop screen reader. Jon Gibbins: And since the release of talkback 9.1 in February of this year, the ways that these two screen readers are controlled and operated are more similar than ever.
Jon Gibbins: The basics are that there are two main interaction methods used by both platforms explore by touch you place your finger on the screen and you move it around and, as you move your finger and the items that are underneath your fingertip are described by the screen reader in audio speech. Jon Gibbins: You double tap items to activate them and then you tap you can also move your finger around and and tap with a second finger to activate them. Jon Gibbins: This interaction is spatial it requires users to become aware of the layout of the screen, so this can be a great way for interacting with on screen keyboard making on screen keyboard more like touch typing. Jon Gibbins: Another method is gesture navigation, which is what is used, most of the time, this is sequential and typically follows the reading order of a screen users will interact with one element on a screen time and swipe left or right to move linearly through this order of content. Jon Gibbins: And then you once you've reached an item, you want to activate you can double tap the screen and it will activate that item.
Jon Gibbins: Something that I check when i'm using a screen reader is page titled, and this is something that often doesn't come up in guidelines and standards. Jon Gibbins: I tested this because I know it's possible to emulate what a web page does so as a move user moves from screen a to screen be. Jon Gibbins: They can the screen reader will announce the title of the new screen to let the user know where they that something has happened, but also to let them know where they are.
Jon Gibbins: it's not well documented for android but it's possible to use the activity title to do this, and it will behave as a web page does. Jon Gibbins: summary element for ios is a little different and doesn't behave in the same way as the page title, but can be used to inform users of the current state. Jon Gibbins: of an APP has they load it so it doesn't change as people move from screen to screen, but does the user know where they are when they open yeah so that's one another approach. Jon Gibbins: keyboard accessibility. Jon Gibbins: This is typically where we look at the focus order on the web and other items like state and management of keyboard focus. Jon Gibbins: While focus on mobile devices is similar there are differences on native native mobile devices, there were two concepts essentially.
Jon Gibbins: there's input focus and virtual cursor so input focus is like keyboard focus on the web, where interactive elements receive focus in a sequence. Jon Gibbins: Virtual cursor is more like the reading order, so the accessibility focuses I call it sometimes were all accessible elements I experienced and not just interactive ones and that's reading the sequence by the screen reader. Jon Gibbins: But on mobile android and ios will go through things like links buttons fields and other controls. Jon Gibbins: But on android in particular there's a misunderstanding, very often around what focus is there is a difference between what the screen reader will go through called the accessibility reversal.
Jon Gibbins: And then, what the the keyboard would go through called accessibility technical focus, so this is more interactive but then focus is broken into two. Jon Gibbins: Sub sections so while there's input focus there's a separate there's a linear focus corner the tab order or next focus forward, and then the other is a directional focus so when using up down left right which items received focus, and these are two separate concepts on android. Jon Gibbins: On ios there is support for keyboard there are bugs with it at the moment but users can navigate using. Jon Gibbins: The tab key arrow keys and then activate items using the spacebar and this typically uses the same functionality that voiceover users to navigate through content.
Jon Gibbins: So there's currently this nest that you can do to implement specific keyboard accessibility differently from the screen reader on ios whereas on android you have a lot more flexibility in that sense. Jon Gibbins: And lastly, I will test with voice to check some other items like that checking the items on the screen actually have. Jon Gibbins: Either numerical labels, so a user can using voice access can say tap 12 and it will take them to the item label. Jon Gibbins: This is a voice access on android on ios we have voice control and it looks very similar, but we can have labels checking that the text labels actually represent the things that. Jon Gibbins: are visible on the screen and.
Jon Gibbins: I will also check resize text and said I wouldn't talk about color contrast too much brighter color contrast so. Jon Gibbins: most modern web sites have responsive designs that adapt to read flow to fit the small screens and it's common find that content on on native Apps reef flows well as well. Jon Gibbins: But it's often the adaptability to changes in text size of forgotten now when it comes to conformance.
Jon Gibbins: The web content accessibility guidelines and the right standards requires us to test text size of 200%. Jon Gibbins: Now, the problem is when translating this for mobile is that is currently no way on either ios or android to set text at 200% so we test these in the closest setting for android this means 132%, which is the largest setting in the font size settings. Jon Gibbins: On ios this means stop number 10 return on larger accessibility sizes and it presents us with more options and on the slider. Jon Gibbins: Stop number 10 is roughly 100 or 235% so it's more than the 200% required for compliance, but the STOP below it is 194% which isn't quite enough so if we want strict compliance, then we should look at meeting the they have the we're looking at should support. Jon Gibbins: text resizing up to up to that level one thing to note, though, is that there are some issues around expectations of how things resize ios and android. Jon Gibbins: Number one on ios when you resize texts tab items don't resize adoption and the things that don't resize include segmented controls.
Jon Gibbins: Instead, there is a different way to accessing larger previews of the text on these items so when large accessibility sizes is turned on for text resizing, then we can actually hover finger and hartford hover and hold our finger over these tab items in a larger preview. Jon Gibbins: Here, this is expected behavior and, therefore, technically, I believe, should pass, whereas on android the text size does change for the sorts of interfaces tap ours, but we ended up with issues around. Jon Gibbins: truncation with text.
Jon Gibbins: Another thing that does not resize on android is the with font size settings is the things like title texts in top bars and generally This is because of restricted space. Jon Gibbins: And finally color contrast, and this is an easy one, I take screenshots or as i'm doing an audit one one thing that will find. Jon Gibbins: color contrast issues is the automated tools, I will also take screenshots and the automated tools don't always find every instance of a color contrast issue, so I will check the using.
Jon Gibbins: color contrast tool. Jon Gibbins: as well, so what does it mean to be accessible on mobile well mobile accessibility is different to the web and it's important to understand those differences, what does compliance look like compliance can be quite fragile currently. Jon Gibbins: Because the guidelines and standards don't always easily translate to native mobile platforms and specifically to ios or android.
Jon Gibbins: Rather than mobile native Apps in general. Jon Gibbins: So how do we test for compliance on mobile Apps testing has some subtle issues to look out for which i've learned from experience, and I hope that this talk will help you in navigating those issues. Jon Gibbins: I really appreciate you listening to me today, and thanks for listening it's time to take some questions. Susanna Laurin: Today Cindy Thank you john for this walk through I know you have material for another three hours but.
Susanna Laurin: I kind of a focused speech, for us, we have some short question, I believe we can manage to. Susanna Laurin: To answer them, so we have a question around switch controls, so when you talk about the differences between a keyboard focus and screen reader focus, where does, which controls in there. Jon Gibbins: Okay, so switch control on ios There again, because we have an accessibility API that switch control uses which it shares with voiceover.
Jon Gibbins: A lot of the behaviors are similar, so there are two things that, in particular, that come to mind one we have something called custom actions that both voiceover on ios and on android have a way of gaining access to multiple actions on a single element. Jon Gibbins: Now that's available to switch control users on on ios it comes up as as the first menu when you're using switch control, so you have access to advanced functionality like that. Jon Gibbins: The order in which content go through go through is defined by that same API However, there are differences in grouping when we're using switch control it's. Jon Gibbins: beneficial to group items together, so perhaps you're going through rows of an on screen keyboard before then selecting the the letter that you want on that road, so there is additional API for checking grouping of things So yes, it is important to test swift control control as well. Jon Gibbins: But it's that specific thing so when we're checking things like focus order, as it were, then that applies to the relevant success criteria and we're keg.
Jon Gibbins: When we're testing for switch access or grouping, I guess, where we're fitting that into like information and relationships almost but it's a user experience issue for. Jon Gibbins: switch control users to make them more usable so how we fit that into the context of compliance and into the guidelines is up for interpretation. Jon Gibbins: But that's that's the that's the issue there on android that it's switch access on android is not as advanced. Jon Gibbins: But it does provide a means to group content together as well, but my understanding of that is that.
Jon Gibbins: That is done for you in the background, so I don't think there is much control that developers have over that. Jon Gibbins: So switch control, yes, definitely worth testing as a as an additional thing, keeping in mind that they are built upon the same accessibility api's has voiceover so yeah I didn't include in my slides, but I would I would test for that as well. Susanna Laurin: Thank you and and and kind of attached to that is it necessary to test with physical keyboard.
Jon Gibbins: Yes, so under the keyboard section I didn't elaborate I guess there's. Jon Gibbins: This testing for keyboard accessibility, with the screen reader attached as well, because there are keyboard commands when running a screen reader so we can attach a bluetooth keyboard to come in and navigate using the screen reader but there's also just keyboard on its own so. Jon Gibbins: On ios. Jon Gibbins: Currently, there are some issues, I know, for example. Jon Gibbins: hybrid views a web view inside embedded within the native APP is currently not keyboard accessible, whereas it is can be navigating using.
Jon Gibbins: screen readers so there there's a problem there, but there are keyboard. Jon Gibbins: controls that should be tested as well on ios the order of content, the focus order and that kind of thing in the behaviors should be very similar if not exactly the same as what voiceover. Jon Gibbins: Does because again it's built on the same API However, there are differences in how keyboard users interact with things. Jon Gibbins: To have the screen reader users interact with things, so there is more of a concept of grouping, so you can use the tab key to navigate to a widget.
Jon Gibbins: And then use the arrow keys to navigate through things, whereas you would interact very differently with that using voiceover So yes, number I think there's Item number four on my list is to test with keyboard alone. Jon Gibbins: And optionally I would say testing with keyboard and a screen reader at the same time, but generally if you've used a screen reader testing and keyboard testing separately, then you've covered the bases keyboard definitely worth testing on android because the keyboard accessibility. Jon Gibbins: API is separate from the API used for talk pack, so I definitely test the keyboard on issues on android because there is that separation. Susanna Laurin: Okay, so I, we need to wrap up very soon, we have a couple of questions left, so we will make sure that john get to respond to this in writings every one of you did a registered today, we can also send this to you in writing, but I think this one could be short, possibly.
Susanna Laurin: If developers use standard components, but accessibility issues still arise, would you advise to develop less robust workarounds or keep it as it is. Jon Gibbins: Generally, if you're using the standard ui components to do things you have 90% of the accessibility there and it's pretty hard to break the accessibility, if you know what you're doing. Jon Gibbins: So.
Jon Gibbins: If usually if you're building things on top of standard ui components, then it's it's relatively straightforward to make something accessible. Jon Gibbins: So I don't think that there should be a reason not to make something accessible. Jon Gibbins: But.
Jon Gibbins: You know, we very often go down the route of making something custom, because we want to a particular. Jon Gibbins: behavior to hope, hopefully, that kind of answers like question anyway, but i'm happy to answer further in context. Susanna Laurin: Okay, thank you very much john, for this is very, very good listening to us always very interesting and I always learned something new, so I don't know if Rachel closing closing words and updates or links or anything you want to.
Susanna Laurin: wrap up with. Rachel Paul, IAAP: That, so thank you both for joining us today, this was our last webinar in the fall series, we will make the recording available and john said he could share his slide so we'll send out a follow up email to that I posted earlier in the chat the link to the. Rachel Paul, IAAP: to sign up for the EU. Rachel Paul, IAAP: newsletter the butcher when the next one will be coming out but i'll go ahead and post that link again if you didn't catch it earlier that's a great way to stay up to date on what is going on in the EU and and upcoming webinars will be doing these again spray.
Rachel Paul, IAAP: I think that's all I am going to thank our CAP Center and our interpreters today, for being here, it was great. Rachel Paul, IAAP: The different languages available. Susanna Laurin: Okay, so thank you everyone, and thank you for following us, this is the first year of the you initiative in I double ap and we look forward to.
Susanna Laurin: Next year upcoming year even more interesting things and hopefully meeting each other in person, so look up for the updates on the event in Brussels, and thank you again join john for joining us today and stay safe everyone bye bye.
2021-12-10 10:50
