{"id":2447,"date":"2022-05-05T11:38:24","date_gmt":"2022-05-05T18:38:24","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/surface-duo\/?p=2447"},"modified":"2022-05-05T11:38:24","modified_gmt":"2022-05-05T18:38:24","slug":"accessibility-dual-screen","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/surface-duo\/accessibility-dual-screen\/","title":{"rendered":"Accessibility in a dual-screen application"},"content":{"rendered":"

\n Hello Android developers! \n<\/p>\n

\n Accessibility is an important step in the design and development flow of any Android application. Ensuring that everyone can use it in any situation will make the experience better, and the app will benefit from having an extended and diverse audience. When you design your app with accessibility in mind, you ensure that people with disabilities understand your application better, benefit from increased user satisfaction and will receive feedback from a diverse user base.\n<\/p>\n

\n An important feature of large screens and foldable devices is the extra space, which helps improve productivity. Users will be able to navigate through your application efficiently only if it is built with accessibility in mind, so you should consider all kinds of disabilities \u2013 be it situational (very bright or very dark environments, cannot use audio) or physical impairments.\n<\/p>\n

\n We recently improved the accessibility of our Dual-Screen Experience Example<\/a> application and would love to share with you the steps we followed. We will dive more into how to enhance accessibility for View-based layouts<\/a>, but these concepts can also be used for an application developed with Jetpack Compose. To learn more about the differences in attributes and implementation, you can refer to the Jetpack Compose accessibility page<\/a>.\n<\/p>\n

How to get started<\/h2>\n

\n There are multiple tools out there to help you get started with testing the accessibility of your Android application.\n<\/p>\n

    \n
  1. \n

    Accessibility Insights<\/a><\/b><\/p>\n

    \n This tool connects your computer to your testing environment, displays what issues are found, and generates a report. This is extremely useful in case you want to use emulators or devices with multiple screens, since you will be able to develop and control your test devices on the same machine.\n<\/p>\n

    \n \"AccessibilityFigure 1: Accessibility Insights checking an application displayed on a dual-screen emulator<\/em>\n<\/p>\n<\/li>\n

  2. \n

    Accessibility Scanner<\/a> and Google Play Store report<\/b><\/p>\n

    \n In case you would only like to work with the device under test, this application can be downloaded from Google Play Store and has the option to create a report by taking screenshots through a bubble button. This is based on the Accessibility Test Framework, which is integrated in the latest versions of Android Studio and generates warnings directly on the layouts. If you are using Google Play Store to distribute your application to users, the framework is also integrated in the pre-launch report<\/a> that is generated after uploading a release.\n<\/p>\n<\/li>\n

  3. \n

    Accessibility in Espresso testing<\/b><\/p>\n

    \n To identify accessibility issues early in the development flow, you can include AccessibilityChecks<\/a> in your Espresso tests<\/strong>, and it makes a test fail when an issue is detected. For instance, we created a custom AndroidJUnitRunner class where we can add settings which apply to all UI tests at the same time (also sets up the HiltTestApplication so we can easily control the components we need inside the tests).\n<\/p>\n

    class HiltJUnitRunner : AndroidJUnitRunner() {\r\n    override fun newApplication(\r\n        classLoader: ClassLoader?,\r\n        name: String?,\r\n        context: Context?\r\n    ): Application =\r\n        super.newApplication(classLoader, HiltTestApplication::class.java.name, context).apply {\r\n            MapConfig.TEST_MODE_ENABLED = true\r\n            AccessibilityChecks.enable()\r\n        }\r\n}<\/pre>\n
    \n  In build.gradle (app)<\/strong>, we just declare this new custom class to be used for instrumentation tests:\n<\/p>\n
    android {\r\n   defaultConfig {\r\n      testInstrumentationRunner \"com.microsoft.device.samples.dualscreenexperience.HiltJUnitRunner\" \r\n   }\r\n}\r\n<\/pre>\n<\/li>\n
  4. \n
    Android Studio lint warnings<\/b><\/p>\n
    \n  Besides the Android Test Framework layouts integration, Android Studio also generates lint warnings<\/strong> when content labelling has not been added to components which usually need it (such as ImageView, ImageButton). Just make sure your layouts do not include AppCompat <\/strong>widgets directly, because those do not generate any warnings<\/strong> and should only be used for custom views. If the top-level activity \/ dialog is provided by AppCompat, it automatically includes compatible widgets.\n<\/p>\n<\/li>\n
  5. \n
    Accessibility services<\/b><\/p>\n
    \n  Manually testing your app using accessibility services such as TalkBack<\/strong><\/a> and SwitchAccess<\/strong><\/a> is important so you can understand the way your layouts are explained to people with disabilities. They demonstrate if someone can easily navigate through your app and reach all the views in the correct order.\n<\/li>\n<\/ol>\n
    Minor changes make a significant difference<\/h2>\n
    \n  After creating a list with all the issues found using the tools described in the previous section, we started implementing the improvements.\n<\/p>\n
    \n  Content labelling \n<\/h3>\n
    \n  The first step was to make sure that all widgets either include contentDescription<\/code> or the android:importantForAccessibility= \"no\"<\/code> attribute. The latter is mostly used for illustrations which do not bring any additional information, so they can be skipped by accessibility services.\n<\/p>\n
    \n  It’s important to have content labels, but it’s even more important that they are descriptive, so anyone can understand what they represent. For instance, in RecyclerView components, we mostly show the values of an item’s details. This information isn’t useful without context, so it’s more helpful to include both the label and the value in the contentDescription<\/code>. Keep in mind that the type of component is already added to the content description by accessibility services (such as “button”).\n<\/p>\n
    \n  As an example, this is how we create our StarRatingView<\/a> component, which is attached to the product items. The stars are illustrations, so we declared that they are not important for accessibility, while for the text we added a more descriptive content label (“Rating: <value>”):\n<\/p>\n
    for (index in MIN_STARS until STAR_COUNT) {\r\n    addView(\r\n        AppCompatImageView(context).apply {\r\n            id = getStarImageId(index)\r\n            setImageResource(R.drawable.ic_star_empty)\r\n            gravity = Gravity.CENTER_VERTICAL\r\n            importantForAccessibility = IMPORTANT_FOR_ACCESSIBILITY_NO\r\n        },\r\n        LayoutParams(heightView.dpToPx(context), heightView.dpToPx(context)).apply {\r\n            marginEnd = starMargin.dpToPx(context)\r\n        }\r\n    )\r\n}\r\naddView(\r\n    TextView(context, null, 0, R.style.GoldText).apply {\r\n        id = textViewId\r\n        text = ratingValue.toString()\r\n        textSize = heightView\r\n        contentDescription = context.getString(R.string.rating_with_label, ratingValue.toString())\r\n    },\r\n    LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT).apply {\r\n        marginStart = starMargin.dpToPx(context)\r\n    }\r\n)<\/pre>\n
    \n  Furthermore, it is important to have unique<\/strong> contentDescription<\/code> values to prevent confusion. We encountered a case where two About<\/b> labels appeared on the same screen while referring to different elements, one being about the About Store<\/b> tab, while the other meant the About App<\/b> menu item. To fix this, we extended the contentDescription<\/code> values to make them specific to the section they were included in.\n<\/p>\n
    \n  Another thing to consider is invisible elements. Even if an element is invisible to users, you may still want it to be recognized by accessibility services. In the Dual Screen Experience example, we set the title of the dialog we are showing to confirm an order even though it is not visible (because we used dialog.requestWindowFeature(Window.FEATURE_NO_TITLE)<\/code>). This way, it won’t show on the screen, but it can still be read by accessibility services.\n<\/p>\n
    \n  Color contrast\n<\/h3>\n
    \n  We worked together with our designer to match the device system theme to the Dual-Screen Experience Example application, which initially had only dark mode support. We wanted to offer both options to users \u2013 light<\/strong> theme and dark<\/strong> theme, to accommodate multiple preferences, various light sensitivities, and to be sure the app can be used in any environment. The main thing to keep in mind is that you need to consider the color contrast ratio of your elements \u2013 for example, the background and foreground of an ImageView, or the color of TextView components compared to their backgrounds. The W3C (World Wide Web Consortium) recommends a contrast ratio of at least 3:1<\/strong>, and you can find more details on the W3C constrast page<\/a>.\n<\/p>\n
    \n  \"SurfaceFigure 2: Light theme vs Dark theme for the Launch Activity<\/em>\n<\/p>\n
    Important aspects for dual-screen devices<\/h2>\n
    \n  When talking about dual-screen, foldable, and large screen implementations, we often use Views or Fragments side-by-side so we can display more content and take advantage of the whole display area. From an accessibility point of view, it is important to check that on normal single-screen devices, the implementation does not add the components on top of each other, because that means a lot of noise for the accessibility services and the application becomes hard to understand. Inside the accessibility testing tools, this appears as with the following warning: \u201cMultiple clickable items share this location on the screen.<\/strong>\u201d.\n<\/p>\n
    \n  Starting with the 1.0.0-alpha3<\/strong> version, our Foldable Navigation component<\/a> uses the replace()<\/code> function for the Fragments instead of the add()<\/code> one. This means that accessibility services will only take into account the current destination of the Navigation component and its layout, without including the startDestination<\/code> of the navigation-graph. The Dual-Screen Experience Example already uses the latest version of this control, so you can try it out inside the app.\n<\/p>\n
    \n  Touch target size\n<\/h3>\n
    \n  Since devices with multiple or large screens are all about productivity, we need to ensure that we use the minimum recommended touch target size for clickable items, which is 48x48dp<\/strong> according to the Material Design Accessibility guidelines<\/a>. This ensures that everyone can easily and quickly trigger the actions they need. There are multiple ways to enlarge the touch target area without changing the appearance of content:\n<\/p>\n