Accessibility Feedback from partners

[JGreenlee]

We are working with partners to evaluate the accessibility of the application. Here I will recap and track some feedback we have received from some initial testing on staging using Talkback on iOS.

Tab navigation:

• Of the "Label", "Dashboard", and "Profile" tabs, it is not indicated which is active.
• Each of the tabs reads twice (e.g. "Label label")

Dashboard tab:

• The charts are focusable but they lack descriptions. (I think we've taken care to provide the charts' information separately as text, so the charts themselves does not need to be focusable.)
• It is confusing when there is no recorded data for the user (we should show "No data" or similar, not blank or "0" values).

Profile tab:

• "Log out" should be grouped as one clickable button, not a separate label and icon
• Each setting row should be group as one element. If the row has an associated action, it should be marked as clickable
• Each modal has a "Close modal" option, and also a "Cancel" option - unnecessary
• In the "My OPcode" modal, the "copy" and "share" buttons are not labeled
• In the permissions modal, there is no indication which permissions are fine vs. broken because the "green checkmark" is not labeled

[niccolopaganini]

Hi. I wanted to keep you in the loop for the testing plan and also like wanted to ask if I should create a child issue for this as to not overwhelm the parent issue.

Reason/ strategy being:

• Testing devices : iOS - My personal device and testing phone, Android - ZFlip3, Pixels on various android versions (not sure if this useful; let me know)
• Install the app from their respective store and then kind of simulate the experience for people installing it fresh.
• And then basically go from there

(P.S. I have already done this and I am in the middle of testing all the buttons (I had some hiccups getting Android 14 on a device that is not natively supported but I am okay now! I just wanted to know where I should document it)

[niccolopaganini]

I am listing down a general list and for phone-specific problems, I am going to list it as (phone-specifc: <model>) <problem> as a lot of these "issues" are more generic with very few phone-specific problems

• The scan-code and paste-code are not being referred to as buttons
• The information icon i is referred to as unpronounceable button
• In the demographics survey page:
   - the Lao Language text in the dropdown menu is not referred correctly
   - The tilde ~ sign is read in the demographics survey page (ought to be included)
   - The asterisk before the questions are also read
   - (phone-specific, iPhone)There is also a "ghost" character in the demographics survey page
   - the next, Return to beginning, and Go to End are referred to as webpage links rather than buttons.
• In the Home Page where we have the Label Dashboard and Profile buttons, the screen reader reads it twice, i.e., Label Label, Dashboard Dashboard, and Profile Profile
• The above also is not being referred to as a button
• In the Label Section, I did not encounter any anomalies like the above but if there is a pop-up, I find that it the screen reader reads the background content first (to be more clear, I mean the content that in the Label webpage first)
• In the dashboard Section, the buttons in the section (except the reload and calendar button) are being referred to as unpronounceable buttons
• In the Profile Section,
   - assuming the option are:

---------------------------
| ID           logo/picture |
---------------------------

  it is being read as ID, emoji name, and then the option as a whole. For instance, if the option says:
------------------------------
| Edit Demographics      👤  |
------------------------------

        - The exceptions for the above are View Privacy Policy on Android and Developer Zone on iOS

• More general stuff that is ubiquitous:
   - Emojis being read
   - If there is a window open, I find that the screen tool often reads the content in the back & requires multiple swipes left/ right or requires the user to click the open dialog box

[niccolopaganini]

@JGreenlee I think the action steps can be as follows:

• In the welcome page of the app, include a link to Open Access Study; referring this issue for possibility of the inclusion of a link for easy access
• Address unpronounceable buttons
• Address the issue of the ghost highlight in the demographics page (I feel like you might know what that may be) - This is from the enketo survey page
• Group the contents in the Profile page (I am not sure how to/ why it is being called like that)
• Address any calls where the text is being read twice (Label, Dashboard, Profile)
• Address issues where they're not being referred to as buttons

Update: Refined this list

[JGreenlee]

Potential solution for in-app links:

https://stackoverflow.com/a/35099864

[JGreenlee]

@Abby-Wheelis Nitish and I found a solution for opening in-app links!

window['cordova'].InAppBrowser.open('https://open-access-openpath.nrel.gov/join/', '_system');

More info on the InAppBrowser plugin: https://github.com/apache/cordova-plugin-inappbrowser/blob/master/README.md

[shankari]

In the welcome page of the app, include a link to Open Access Study; referring this issue for possibility of the inclusion of a link for easy access

I don't see a link to the issue - the link is to the join page [issue](https://open-access-openpath.nrel.gov/join/)

I would be really reluctant to add a link to the welcome page that allows us to bypass it in any way. Our primary use case for this app is working with partners for their data collection. So the common case, and the case that should be optimized, is for people to scan a study code.

I am concerned that adding a link to the open access study will be confusing - ("wait, so which QR code should I scan?"). We have had at least one use case (Durham) in which a user, through following the instructions at:
https://www.nrel.gov/transportation/openpath-participant-guidelines.html
joined the open access study by mistake.

Thoughts?

[niccolopaganini]

I spoke with Jack today and he told me that the majority is researchers (implying that the smaller subset is people who use open-access). Prior to gaining this information, I went with the conversation with people; the information regarding to open access study was kind of ambivalent, which is why I thought it would be nicer to have it while I'm working on this PR. (Rather than providing OPcodes in previous versions, I thought this would be a good middle ground). Another reason I thought of this is because visually impaired people might have a hard time navigating through multiple steps to get/ scan an OPcode, which could be a potential deterrent.

[shankari]

I spoke with Jack today and he told me that the majority is researchers (implying that the smaller subset is people who use open-access).

I don't even know what this means. The majority of people who have installed the app are assuredly not researchers - they are part of the various programs that we partner with.

Prior to gaining this information, I went with the conversation with people; the information regarding to open access study was kind of ambivalent, which is why I thought it would be nicer to have it while I'm working on this PR.

Prior to this, all your conversations have been with other interns, not with any externally facing partners or customers. There are < 10 interns. The Google Play version of the app alone has been installed by 500+ people. You cannot generalize from a corner case.

Another reason I thought of this is because visually impaired people might have a hard time navigating through multiple steps to get/ scan an OPcode, which could be a potential deterrent.

Even if you add a link to the open access page, the visually impaired people have to copy and paste the QR code, so I don't see how this helps in any way.

[niccolopaganini]

Even if you add a link to the open access page, the visually impaired people have to copy and paste the QR code, so I don't see how this helps in any way.

I cannot answer the first two responses just because of the fact that I don't have enough information regarding this. However, I feel like copy-pasting the OPcode from the webpage to the app would make it an easier process (atleast, that's what I think from my perspective).

[JGreenlee]

Thoughts?

I do think it makes sense for there to be some path to get on open-access for someone who may have stumbled across the app from the store and not from the join page. We don't really know if / how many people would be on open access if there wasn't this barrier.

I think we can structure the UX in such a way that minimizes the likelihood of someone joining open access when they were meant to join a program/study. I understand the concern there and I definitely don't think we should put a big "Open Access" button on the front page for it to be thoughtlessly clicked on.

I think there can be something like "Don't have an access code? Learn more"; it just needs to be placed lower in the visual hierarchy to convey that it is subordinate to the main flow. I think a fair solution is to literally put it at the bottom, as plain text, ~12pt font, footnote-style. Not colored or outlined and not a button because we don't want to make it seem inviting.

From this, we pop up a dialog, explaining open access and how it is only for people not recruited to programs. Now at the bottom of the dialog we'll present 2 options, i) "Dismiss" (this one is colored / emphasized) and ii) "I'm not part of a program" (de-emphasized so they have to think about it before clicking). Only upon clicking this would we redirect them to the open access join page.

This is not a high priority but I can wireframe if there is interest.

[JGreenlee]

I spoke with Jack today and he told me that the majority is researchers (implying that the smaller subset is people who use open-access)

I can further explain tomorrow to help you contextualize what I was trying to convey today

[shankari]

I think there can be something like "Don't have an access code? Learn more"; it just needs to be placed lower in the visual hierarchy to convey that it is subordinate to the main flow. I think a fair solution is to literally put it at the bottom, as plain text, ~12pt font, footnote-style. Not colored or outlined and not a button because we don't want to make it seem inviting.

I would be open to this, but I just don't see that this is a huge priority because...

We don't really know if / how many people would be on open access if there wasn't this barrier.

We are not really doing anything with the data collected by the open access study. It's just sort of there. We don't even use it as a control group in any of the analysis yet.

This is not a high priority but I can wireframe if there is interest.

Right, this is not a high priority, and I don't know why we should focus on it over any of the other improvements that we need for the UI. In other words, this is only useful if the the reward of getting more open access data is greater than the risk of people joining the wrong study.

If we can think of a really strong use case for open access data, I would be more open to prioritizing this.

[niccolopaganini]

It is definitely my fault for kindling this because previously, the app used to provide an Open Access Opcode making it easier. As previously stated, I felt it would be much easier vision impaired people to just navigate in their mobile device and copy the code. Considering we give out OPcodes to programs, I have removed the button and restored it back to the previous iteration.

[shankari]

It is definitely my fault for kindling this because previously, the app used to provide an Open Access Opcode making it easier.

I don't understand this. We have never, in NREL OpenPATH, provided an opcode in the app. That is the one lesson I learned from e-mission, so OpenPATH has always waited for the user to do something explicit to join a study.

[niccolopaganini]

I was referring to this:

I took this screenshot on May 5 2023 and I was referring to this (I guess this is what you mean by:

That is the one lesson I learned from e-mission, so OpenPATH has always waited for the user to do something explicit to join a study.

)

[shankari]

Even back in May 2023, you would have to first scan a QR code from the open access study page to get here. That's how we knew how to create a token that starts with nrelop_open-access... (as opposed to nrelop_nrel-commute or nrelop_smart-commute-ebike or anything else.

And right around May/June 2023, we deployed "single scan" so that we no longer have this screen in the onboarding flow. You can see from #850 that the code was done around May 20th, so it was probably on production in early June. In this case, there only one token and we infer the study/program from it.