Mobile Accessibility Issues (contd.)

Hello all, welcome back to our course on digital accessibility. And uh this is a continued topic uh from the previous session uh where we talked about mobile accessibility issues and uh we will continue into some deeper investigation and uh various aspects related to the POR principles and we'll try to kind of break down the W CAG uh guidelines particularly for uh mobile accessibility and how we can utilize them. what are the most commonly occurring issues in each category and u we will try to understand uh how we can also parallelly analyze our existing apps from the lens of PUR principle. So just um a warm up regarding the PUR principles. So this is uh from the previous session and we have also had uh one more deep dive session on uh PO principles themselves and compliance in general involves integrating accessibility from the beginning of the design and development process itself. And following these principles of accessibility are key to making your product accessible in the first place. and uh what each of them means and what are the various issues which come under each of them is something which we will uh discuss in this session. Uh so roughly speaking when we talk about perceivability uh under this uh category we uh look at information communication and how properly or how uh in various ways your information is being communicated effectively to the diverse set of users. Right? So basically uh in the previous session also we discussed that this may primarily align with more output devices and related technologies different types of outputs multimodal outputs and u uh aspects of output. So when we say output we we talking about the display we are talking about the audio we are talking about the video we are talking about uh virotactyl feedback all of those uh integrated together form your perceivable uh perceivability of your product and uh how in what what ways you can make all of those feedback systems as well as output systems accessible to a wide variety of users is something which we'll try to understand in terms of operability which is the second O of uh um principles uh second part of the PUR principles and is stands for O is uh related to the functionality or how and in what manner uh users with diverse set of uh abilities can interact or engage with your product. how and whether whether they're able to operate your product, whether they are able to complete uh tasks uh with your product. So this particular principle is primarily catering to the a wide variety of multimodal input devices. So when we say uh keyboard, we we can say the touch capacitive display itself of your mobile phone. um the various aspects of the display itself, the size of the button, uh whether it is um uh uh you know allowing enough time for operability, all of those facets come under uh operability and we will also uh try to understand u each different aspects which come under mobile accessibility in this session. Uh moving to the U which stands for understandability. So uh in this section we talk more about the semantic aspect. So the processing part right so I I'm sure all of you uh might have studied um you know the input processing and output uh system uh and feedback loop which is how any system works right it it it is how uh any system works. Uh so it's basically like this right so this is in input processing output. So here we are saying um the perceivability the operability and processing is the semantic part which is the understandability of the information. So this is uh how the user is actually functioning. This is the system of the user and uh here we're talking about the simplicity. We are talking about consistency. We are talking about descriptions. We are talking about providing uh uh effective signages on your buttons etc. Clear messaging uh clarity of communication not too much cognitive load uh not too dense. All of those facets come under understandability. Then R stands for robustness and robustness in is to ensure compatibility with a wide range of assistive technologies which are already existent on the hardware itself, your mobile device. So something like a talkback which is there in uh Android or a voice over which is there in uh iOS systems and other kind of um sensors and all of those the limiting or the drivers which are there for each sensor. So for example camera has its own driver. A mic of the phone may have its own driver. So whether your app is actually compatible with all of those other systems of the existing hardware or not is also part of the robustness. So uh let us try to understand um the various facets of it. And apart from these, it is always a key practice to make sure that your system is regularly tested with automated tools as well as with real users. And we have discussed this earlier as well. Only automated tools may not give you a very comprehensive understanding of what issues or what are the different reasons why uh your product is failing a certain accessibility compliance criteria. Um but um uh and uh also uh inputs from real users and data collection with real uh users will help you understand what are the different aspects and it uh basically goes beyond just the guidelines which are uh mentioned in the W CAG. So all of those facets need to be covered and that could only result if you are doing regular testing and co- uh building with your uh real users. So this is the resource I think which we've uh kind of browsed through um uh in the previous um session as well. It will direct you to the W CAG uh standards and guidelines for mobile particularly. You can browse through this as well. So it can help you in uh understanding the different success criteria for um the various aspects. What are the different criteria and how it uh needs to be applied uh all of those what falls under this criteria. So when uh an accessibility audit is being done this this document would be referred to and this is something which you should be referring to at the time of design also but this is the second step where you're talking about the criteria. Let us do a more fundamental uh analysis of what are the different kinds of issues which fall under each principle from a design accessibility interaction design perspective and then uh as in when you will read into the each criteria the techniques for implementing it you will be able to find in that other document. But let us try to understand each principle and what are the different aspects which are related to each principle. So what I have done is I have not put all the text on the slide and with every principle we will actually go to the W CAG uh document itself which is quite comprehensive in itself and it will also uh help you understand how to go through that document yourself also. Right? So how to refer to that document is something uh we will kind of try to understand while also trying to understand the different principles and all of the issues that come under each principle. So the first principle is uh perceivability the P. So the first principle is perceivability which stands for P. Uh the most commonly occurring issues is that uh mobile itself offers a smaller screen size which limits u you know motor functionality. The amount of information you can pack on each screen is also gets limited. uh there has to be zoom or magnification uh features on your u on your app. Then there are contrast related issues. So let us uh try to understand what all issues are there. So as soon as we click uh to this uh document, it leads us to this document and we'll try to understand how we can uh read this and uh it will be helpful for us in the design. So um if we go through this the mobile accessibility considerations primarily related to principle one which is perceivable. So first is small screen size right. So small screen size is a common uh characteristic of a mobile device. uh the exceptional resolution of uh the screen um theoretically enables large amount of data for now our devices have very high resolution uh displays which can allow technically it will allow you to pack a lot of information on the screen but when it is actually rendered on that surface so I'm using my phone for reference uh thinking that this is like a standard uh Android phone then this is what roughly the size of each uh device would be and um it roughly uh because an an adult standard hand also has roughly uh falls under the same um um measurements. So the limitations are not imposed by the technology rather the limitations are imposed by the human ergonomic data right so human anthropometric data which is what uh your finger size your thumb size your palm size how much you can navigate the flexibility of it and then all of this is a best case scenario. If there are other limitations like um um you know a person may having a missing finger or they may have um fine motor skills related issues, they may have cerebal pulsy motor uh such motor issues are there or there may be issues such as uh um blindness or other sensory deprivation issues or there may be other seizure kind of cognitive issues which may result in shaking of hand or she seizures. So there is a lack of controlled motor movement uh that those aspects may also uh be present. So then uh packing a lot of information in the one in one screen becomes very difficult uh for people to understand. Uh so that is why we are saying that actually the display or the um device is not really imposing a a constraint rather the human themselves is creating uh the constraints and uh that has to be acknowledged and uh catered to in order to make the interface accessible and usable by a wide variety of users. So basically the small size of the screen places practical limits on how much information people can actually view at one given time. Right? Especially um especially when magnification is used by people with low vision. So if magnification is used then the density becomes even less because the text is bigger. Right? So but in that case let's look at some best practices uh what are the various aspects. So minimizing amount of information that is put on each page compared to a desktop or a laptop version can provide a dedicated mobile version or responsive design. Keeping all of this in mind while creating your product is very important. uh a dedicated mobile version um may contain uh content tailored for mobile use. For for example, the content may contain uh fewer modules, fewer images, focus on important mobile usage scenarios, etc. A responsive design uh contains content that roughly stays the same but this stylesheet so the CSS itself may render it differently for a different orientation or a different screen size right uh depending on the viewport width. For example, a narrow screen, the navigation menus um may be hidden uh and automatically, you know, the dashboard automatically gets hidden into those three lines and drop-down. So, uh all of those things are already there, but you have to take care of uh doing it providing a reasonable uh default size for content and touch controls. So uh so there is also a section on what should be a target size and uh spacing to minimize the need to zoom in and zoom out all the time again and again. Uh adapting the length of the link text to the viewport width. So many a times you've seen that the u uh when whenever there's text which has hyperlinks they are very long or something like that then it becomes very difficult to u u you know touch them and uh even in the responsive uh if it is a link then automatically it will show you the entire text. So make sure that the um displayed text which has a hyperlink is like a label. It's a description not the link itself as the text. So all of these small issues may seem small but all of these uh result in criteria failure and hence non-compliance. So it is important to understand all of these uh aspects. positioning form fields below rather than beside their labels uh in a portrait layout. So, so that it is more convenient to see uh uh it in a portrait layout. Then the other aspect is the zoom or magnification part. So variety of methods allow the user to control content size on mobile devices with small screen. So not just um even if your website or your platform is not responsive, the OS uh today itself has these accessibility uh features embedded in them. So the application should be able to respect user preferences which are there on the base device. Right? So many times we have seen that um uh like for example iOS has assist assistive touch where it it it it's like a zoom lens kind of a thing whenever you uh kind of touch but then uh as soon as an app which is an external third party uh creators app it is opened that iOS assist assistive touch fails to interact with that particular app. So it is then useless. So all of those facets uh uh the app should be able to uh adapt with because they are already there on the base phone or the base device. So uh the methods for example include so as we said OS level features. So make sure that the default text size which is mentioned from the display settings from the mobile phone itself uh is respected by the app code itself. uh magnification of the entire screen which is typically controlled uh by the accessibility settings of the device. The app should be able to respect that preference. The magnifying lens view under the user's finger again specifically controlled by the accessibility settings. Uh this is called again assistive touch. Uh so that part also the app should be able to inspect. Then there can be browser level features. So some of uh some of the users may have some assistive plugins installed on their browsers or the browser themselves may have accessibility features which the website or the web-based platform is not able to respect. So the code itself should be open to adapting as per the base platform which is either the mobile device or uh the browser. So for example um uh success criteria that is most related to zoom is resized text and it's a double A level. So for example success criteria uh 1.4.4 4 requires text to be resizable without assisted technology by up to 200%. Right? Which is double. To to meet this requirement, content must not prevent text magnification by the user. So if the user is trying to magnify but the um the content or the platform or the app is not allowing them to magnify then it is a success criteria failure and your um um your app is not complying with the 1.1 1.4.4 criteria of compliance. So this is how it basically fails right. So all of this is that's why important to understand. So there can be some ways you can actually uh do use to ensure the uh you know that there is a successful uh criteria compliance to so for example ensure that the browser pin zoom is not blocked by the pages viewport meta element. uh support for system fonts that follow platform level user preferences for text size uh is available on your product or your website. uh provide onpage controls to change the text size or you can provide a panel which I think you might have seen in a lot of uh websites which is there either you provide that which is your which is embedded in your code or you allow the user or allow the code to access the system uh system level or browser level preferences and use that adapt that in the um application itself. So either of the two have to be done. Then moving on to contrast which is one of the key components of the perceivability uh aspect. Um mobile devices are more likely uh to be used in varied environments including outdoors where there can be uh excessive light or glare uh from the sun or other strong lighting sources. So in these scenarios uh it heightens the use of good contrast for all users and may compound the challenges that users with low vision or other uh disabilities may have. So um accessing content with poor contrast on the mobile phone uh may be um you know one of the reasons for comp non-compliance. So again for example uh criteria 1.4.3 is related to contrast which is like a minimum criteria on level double A which requires a contrast of at least 4.5 is to one uh for your base font and your three 3 to one for large scale text or headings etc. So this success criteria allows for different contrast ratios for large text. Allowing different contrast ratios for large text is useful because larger text with wider character strokes are easier to re read at a low contrast, right? And this allows the designers more leeway for uh contrast of larger text which is helpful for content such as uh titles. So um a ratio of uh a ratio of 18 point text or 14 point text um was judged to be large enough to uh have a lower contrast ratio while uh again while displayed on a 15-in monitor versus um a smaller but the same text when moved to a mobile device uh and different conditions. So this allows for lesser uh contrast on larger text must be considered carefully for mobile apps. So for example, I mean if the even if it's the same content but the point size font whenever you project it on a bigger display versus a smaller handheld display uh the size automatically changes, right? So then uh the criteria and the ratio may also change. So one should keep all of these facets in mind. For example, the default point size uh for mobile phones must be larger than the default point size used for a non-mo device. So when determining which contrast ratio to follow the def uh developers should always um ensure to apply the lessened contrast only when the text is roughly equivalent to 1.2 times bold or 1.5 times of what is the default platform size. So basically what what accounts for as a heading in a mobile device is that it should be roughly 1.5 times of your body text then only you can use the lower contrast ratio otherwise which is 3 is to1 otherwise it should be 4.5 is to1 contrast ratio. So similarly there are some more aspects. So now let us uh so now we are able to understand which facets kind of fall under each category. Moving to the second principle which is operability which is large for O and uh this majorly as we discussed earlier looks at the u usability or adaptability of your product with respect to various kinds of input devices right so be keyboard be the touch targets speech be it uh um other manipulation gestures voice related aspects all of those things right so let us uh try to understand each of them so again the link has directed us to the same document but with a um different heading the different section uh so now we will talk about considerations primarily related to operability so the first one is Of course, keyboard control for touchscreen based devices as well. One would think that because the application is going to run on a touchscreen device, there's no need for it to be compatible with a keyboard. But that is not the case because many a times there might be users who want to interact with it uh through a keyboard. So let us uh go through it uh to some extent. So mobile device design has evolved away from built-in physical keyboard. So keyboard by definition is a very tactile um interface right because it has protruding buttons. It is easier to locate where which button is. Some of them have different sizes or shapes which also the important ones like enter or delete or control or spacebar right which actually is a very strong tactile feedback which is missing in a flat uh smooth screen right uh so towards devices that maximizes touchscreen area and display on uh uh an onscreen keyboard when the user has selected the interface control. However, keyboard accessibility remains as important as ever and most major mobile operating systems do include inter uh keyboard interfaces, right? Allowing devices to be operated by external physical keyboards either through Bluetooth or USB on the go etc. or alternative on the screen keyboard so like scanning on screen keyboards etc. Supporting these keyboard interfaces benefits several groups which with disabilities. So groups with visual disabilities of course as we said it is uh it offers a lot of tactile feedback and is th does useful for um persons who are visually impaired. So has separate keys uh key nibs more predictable key layout because it's like a standard uh querty layout is something which is there across the board. Uh then people who have dexterity or mobility related uh disabilities who can benefit from keyboard optimized to minimize in avoidant presses. So reduces error, has more room for uh error and uh because the keys are differently shaped, they are spaced uh decently, they have guarded keys. Uh also then people who can be confused by the dynamic nature of onscreen keyboards can also uh benefit from the consistency of a physical keyboard. So depending on the OS or depending on the brand of the phone you are using, many of times the default keyboard, the design of it, the shape, the size of the keys or even the hidden keys like uh which button unfolds, the number keys, which button unfolds, the special characters, all of those may change with the brand or the OS as well. So uh that unpredictability also gets reduced in a physical keyboard because it's largely standardized. So keyboard access is level A uh criteria. No keyboard trap is uh a level A criteria. You can read up on uh these in the other uh document where all the criteria are listed which I had uh shown earlier which is also linked on the PPT. The second aspect is uh touch target size and spacing. This is one of the most important aspects because all our interfaces which are designed for the mobile have buttons somewhere right because some there is some call to action. There is a submit button or an okay button or press this to do X right. So um this this is one of the most important uh aspect. So the high again the high resolution of the phone now displays uh means that many interactive elements actually can be packed. So theoretically there is a lot of room to pack um a lot of uh elements but these elements must be big enough and have enough distance between each other so that the users can safely target them by touch. And of course we also we're talking about the thumb mostly uh because that's uh the opposable thumb is primarily used which is again a little bit bigger than the rest of the fingers. So that is also important. So and then based on that uh ensuring that touch targets are at least 9 mm high by 9 mm wide is something which has been described. then ensuring the that touch targets close to the minimum size are surrounded by a small amount of inactive space. So there has to be enough um border or a boundary around an around a active pressable button so that by mistake you're not pressing other buttons. So it is important to note that this size is actually not dependent on the screen size. uh screen magnification should not be needed uh to obtain this size. So you should not assume that um okay it can be magnified to 9 mm by 9 mm but that's not the case right. So uh it uh uh it should be the minimum size. Then we come to touchscreen gestures. Um so again mobile devices are designed to primarily uh be operated using gestures also made on the touchscreen. These can be like double tap or multip multiple fingers drawing shapes etc. And some mobile operating systems provide workaround features that can let the user uh simulate complex gestures uh with simple ones using onscreen menu. So for example, I'm sure you might have used the uh swipe uh typing mode. I I constantly use it instead of typing each key u like one by one. If you kind of swipe the letters of the joining uh the letters uh which will form the word that you want to put. So if it is car you are swiping your hands via C A N R. uh the system is able to roughly predict that okay you want to uh spell out car and it'll give you or maybe a close um relative of the same word and you can choose which one is it right and it also now with adaptive uh systems and ML based algorithms it has become largely more adaptive so uh so all of these aspects are there again in the OS level so your app should also be able to uh leverage all of those features which uh are already present on the device which is like multi-touch features and all of those right so gestures should be as easy and as possible to carry out and they should be very intuitive. So something like a right swipe or left swipe is something uh which we are already you using in say uh in our photo gallery right so right means next uh right and if it is not as intuitive not the same in your app if you have a gallery of images on your app and it's not swiping right to show next or doing some other gesture to show next then it becomes very unpredictable and very difficult to interact with. So you have to keep that in mind when you are creating gesture based interactions on your uh product. Then device manipulation gestures, right? So in addition to the touchscreen gestures, many mobile operating systems al also provide developers with control options, right? Shaking or tilting. uh maybe shaking can turn on your torch for example and I know that this is there in uh some of the common phones like you shake and it opens the camera or you you know kind of do this and it automatically uh changes the orientation of your uh display. So all of those things are uh there right? So again this is an OS level. So your app should also be able to engage with similar kind of device manipulation gestures and it should allow uh you to do it placing buttons where they're easy to access. Right? So this is again very important. Uh so so basically which which means that this is the entire workable area that you have. Uh and uh then usually people have also done a lot of research on how users hold it most commonly what are the most common you commonly used fingers uh which are there. So where in this entire area where the buttons need to be placed so that they're easily accessible. Again this is again a very abbleist approach. We are assuming uh that the thumb is uh able to move. But then again even this you can see is limited right? I if if something is placed here I will have to use the other hand. If something is if something is placed below uh my reach that down here I will have to use the other hand. Then that basically excludes people who are unable to use both of their hands uh at all times. So we have to be very uh careful about where the position is there and always uh think about okay uh if this is something which I want the user to press then it should be placed in those regions. If there is something uh which I don't want to be accidentally pressed then they can be placed in the peripheral regions which is as u as mentioned like above or below. So you might have seen the navigation uh bar basically hides up and you can swipe it to swipe down to bring it down all of those things. So it accidentally doesn't appear every now and then right. So it's hidden basically. So all of those aspects uh one can utilize. So moving to uh the third principle which is again understandability and uh as we have discussed earlier this primarily uh looks at the semantic aspects. What is the meaning of semantic association? Is how people understand meaning or how we associate meaning to a text or meaning to a gesture, meaning to a layout. So all of those aspects come under understandability. So now it has the link has taken us to the same document and now we will try to understand each of these aspects. So um various aspects like changing screen orientation. Um so if some applications automatically set the screen to a particular orientation and expect that the user will respond by rotating this mobile device to match. However, some uh users have their mobile devices mounted in a fixed orientation. So for example, if it is mounted on a wheelchair etc. it may not be as easy to rotate it. Therefore the mobile applications should try to support both orientations uh if possible. Um if not possible they should ensure that it is easy for all users to change the orientations to return to a point at which the device orientation is supported. Then consistency is something I think we have discussed uh several times. uh components that are getting repeated across multiple pages in in one task. They should appear in the same position in each page. They should appear in the same color. They should appear in the same size uh possibly. uh so then uh that consistency uh helps people in um understanding that okay this is a subset of that or this is under this or I'm still completing this particular task because this heading is still going on. Um again uh it is consistency also is important when your product is available both in a web bl web based uh platform as well as an app particularly say banking websites. Uh so they have always have like an online net banking version and now they also have app. Uh if the interface the overall look and feel the im the icons which are used uh are not same uh the colors which are used the dashboards how it is organized it's not similar to each other then it becomes very difficult for the users to understand the meaning or associate the meaning of one icon u you know consistent uh consistently across the usability of the same um uh web or slash mobile application. So consistent navigation and consistent identification are two very important criteria. Positioning important page elements before the page scroll. So the small screen size on many uh mobile devices limits the amount of content that can be displayed without scrolling. Right? So how uh how you decide uh what are the priority elements which should appear on the landing screen and what should appear after scrolling is something that needs to be uh decided by the design team. uh and uh so positioning important page information so that it's visible without requiring scrolling uh can assist users with low vision and other cognitive impairments. So if a user with low vision etc uh has magnified the screen and only a small portion of it is visible then placing uh important elements before the page scroll allows uh those who use screen magnifiers uh locate important information without having to scroll to view uh to move uh scroll the view to move the magnified criteria. So in what so completing this criteria or completing this aspect uh the step one is to understand and recognize what is important and that may change uh with the context and the use of your um product. So first is to identify what is important. How probably you can do that is uh what are the major objectives of your product list that down and based on those objectives try to chalk out three to four tasks. So for example uh let's take example of a net banking platform. So the major objective is I want to manage my finances. I want to manage my uh bank uh account. So maybe two three popular tasks would be that uh a I want to um check my uh balance and print a statement. That is one task. Other task can be I want to again check my balance and if there is enough money I want to open a FD. uh then they may be I want to log in and I want to open or uh pay a premium to a policy for example which is already going on. So similarly you can chalk out two two three four tasks and during those tasks what are the things which are primarily coming up again and again or what are the things which I need to enter to begin the task. what are the things that the system needs by default um in order to even complete the task. Right? So based on that you can identify what are the important information for each task and accordingly place them on the screen so that those tasks can tasks can get initiated with the right set of uh uh information both to the user as well as for the system and then as and when required they can move to the next steps. You can also decide based on the task how many steps it should be broken into. So the number of steps also decide helps you decide how to place how to design each screen. Right? That brings us to the next uh point which is grouping operable elements that perform same action. So then um so as we said so for example if you divide it into tasks if there is some um element which is talking about entering your name or age or whatever date of birth or entering information then it is grouped in one window and it is all happening in the same uh set. Then providing clear indication that elements are actionable. So this is again very important. The actionable buttons or need fields that need to be filled should be very clearly u demarkable both from a visual perspective but also from contrast. all of those visual perspectives as well as from a screen reader or assisted technology related perspective without which um so again you can go back to your our session on affordances and you can see how we can design call to action in a better way what not to do so that you don't enforce a negative call to action so it is very important uh that um uh the actionable items are indicated appropriately through different means in your product. So some examples can be conventional shape like so like a button shape which is like a rounded corner rectangle with drop shadow which makes it look like a pressible or checkbox or select triangle with arrow pointing downwards or something like that right or icons where which are conventional icons like a question mark home icon burger icon for menu floppy disc icon on for save, back arrow for going back. So these are like commonly familiar icons. So if you use something new uh every time then it becomes very difficult for people to understand. Color offset. For example, shape with different background color to distinguish the elements from the page background. Different text color, underline text for links, color for links, conventional positioning, commonly used uh positions such as top left position for back button um or uh menu items which are left aligned, dropdowns for navigation. These are these are there in most of the websites. So uh many times you should not uh just in an attempt to be out of the box uh don't um undermine the value of familiarity right which uh because that also helps in the building the understandability of your product. So just to be different or new or fresh don't undermine the value of uh what is familiar what is uh standard. So because um that would help your users to uh access it more with more convenience. The learnability curve can be uh very flat. then provide instructions for custom touchscreen and device manipulation gestures. So, uh the ability to provide um control via custom touchscreen and manipulation gestures can help developers create efficient new interfaces. So however like many people uh dest remember also. So again make sure that you use the power of familiarity here as well or you give some instructions or um overlays or tutorials in your um in your application that okay this is how you can do it. uh there are some run throughs which you can do uh which you might be seeing in a lot of applications these days. So uh then moving to our fourth principle which is robustness. Um then all of robustness we talk about um accessibility in terms of uh compatibility with different allied uh assistive technologies or different platforms or different OS. Uh so let us talk about all of these. So under principle four you can set the virtual keyboard to the type of data entry required. So for example you might have seen in many of the apps now that uh if the pin needs to be entered uh it automatically opens the numeric keyboard uh it doesn't open the string keyboard. Right? So that saves the user additional step that saves incorrect entry that saves the time add is added uh adds ease ease of use then provide easy methods for data entry. So it your u a lot of information is already available on your mobile devices either the base OS or your browser settings itself. So wherever uh possible it should allow um autocomplete or autofill and all of those things. Mobile devices provide many features to help users with disability to interact with content. So for example, every time I don't need to enter my username or password if even if it is a banking application I can enable my biometric information biometric login and I need to just scan my finger in order to login into the app. Right? So it saves a lot of time, saves cognitive load of remembering the password uh which may be a challenge for a lot of u people. the features and functions available different uh differ depending on the device and the operating system. So most platforms have the ability to um set large fonts but not all applications honor it for the text. So again I think this we have discussed earlier also that whatever properties the platform that means the base device OS or your browser already has the user has entered their preferences. The application should honor those preferences otherwise uh the users will have to reenter it or they may find it difficult uh to um understand. Okay. To so to summarize we in this session we again dive deep into the issues related to mobile accessibility as peri principles. We discussed some key principles uh related to mobile accessibility. I also shared um major usable resources primarily uh from the W3C website. You can also go to those links. And uh this is a very uh good book for um understanding uh designing mobile apps particularly making them accessible for a wide variety of users and uh it you know talks about different use cases different techniques to make um implement um accessibility criteria how to avoid failure of accessibility criteria. So maybe you can browse through uh this book. This is available on all uh popular marketplaces. Uh so thank you uh for sticking around for this session. Uh we will see you again in the next session.