RadarCOVID/radar-covid-ios

Accesibility problems

applecoding opened this issue · 3 comments

  • The app uses a non dynamic font type (Muli) that causes the app doesn't support accesibility text modes for people with visual disability. It must be changed to System font types and styles.
  • Policy privacy and use conditions fields are so small for people with move disabilities.
  • An image checkbox is not Apple UI standards compliant. An app is not a web page. You MUST use a UISwitch. In fact, there's a hidden UISwitch for a bad patch for accessibility that is confuse for voice over.
  • Many image items are not set properly for to be ignored for the accesibility API.
  • Apple Interface Guidelines said you must use UIPageControl for an welcome tutorial, not a "Continue" buttons.
  • I suggest the use of the app Accesibility Inspector in Open Developer Tools in Xcode, to find and resolve all accesibility issues.

Best regards,

Thanks @applecoding for raising these issues! I think it has been a big surprise for lots of us to find out how little thought has been put in making this app accessible. It is good to see that they're finally making some improvements but there is definitely still a long way to go. Which is what happens when accessibility is an afterthought in your project instead of something you consider from the very beginning, starting with the design process.

I'd like to add some more issues I've seen for now, if it is ok (in no particular order):

  • No support of Dark Mode and even Smart Invert Colors (some images could be excluded from being inverted for a better experience).
  • Bad use of accessibility hints. I've seen that the accessibility hint with the key "ACC_HINT" is widely used across the app. Hints are optional and should be used to provide further clarification on how a UI control works. Double tapping a button to action it is how VoiceOver works and therefore it seems unnecessary.
(lldb) po "ACC_HINT".localized
"Pulsa dos veces para activar"
  • I haven't been able to test it on a device yet, but when starting the app and the tab bar controller is created, it looks to me like the strings are not yet available and that keys are being configured as accessibility labels, hints, etc. I can reproduce it by, for example, adding a breakpoint in line 75 of TabBarController and running the following command in the console.
(lldb) po "ACC_HOME_TITLE".localized
"ACC_HOME_TITLE"
  • The fact that the language is configured in-app, instead of using the one configured in the device's locale, means that I could have the app in Spanish but the system in English, for example, leading to a very bad VoiceOver experience.
  • Accessibility perform escape gesture not working in multiple parts of the app. Not completely sure why because it should just work when using a UINavigationController.
  • The heading accessibility trait is missing from many headers in the app. One clear example is the title in the view you access by tapping the third tap with the question mark icon, that says: "Para más información".
  • Links shown in the app could have the link trait.

Thanks for your feedback. Team is working on making the APP more accessible in the next releases. You should check the 1.0.7 version for some improvements in this area.

We are currently working on it, many accesibility issues has been fixed but we are still pending a few.