Develop: Set example for accessibility metadata

[mdconatser]

As a user utilizing accessibility features, I want the design of the application to have "tagged" elements so that I can intuitively say the name of the element to select it by voice. I also want it to not have extraneous elements read by the screen reader. Also for the screen reader, I prefer more commonly used actions or "top-level" information to be read first so I have a better idea of what the phone is displaying without looking at it.

Acceptance Criteria

• Actual code changes needed for elements to easily be accessible by voice input (element labels?) are added to the current application (or new pages if the work has already been completed)
• Investigation into what other code changes we might need to better support accessibility tools based on the current application (will create more tasks as needed based on this research)
• Pay attention to if we can skip elements that won't be necessary for the screen reader
• Document any relevant content in the Programmer guide (draft thoughts of usage and importantly the "Why")
• Updates SRS and STP (and other docs if necessary)
• Add/Update relevant unit tests

[mdconatser]

These look like helpful posts for this:

https://tonyowen.medium.com/accessibility-in-flutter-592f2e760149 https://medium.com/flutter-community/a-deep-dive-into-flutters-accessibility-widgets-eb0ef9455bc

[tatikozh]

@mdconatser, @cthorn2, @shaneknows While working on semantics noticed that VoiceControl would get confused if we duplicated elements on the page. After the initial tap, the system will assign numbers to duplicate options and expect the user to tap one.

[cthorn2]

Let's pull it from the top. I have been asking for feedback on the designs, not from the group suggested, but coworkers/contacts. I've gotten some feedback that this design is preferred for the main menu. If you agree, I'll convert to Flutter/Dart and upload with the requested change.

[shaneknows]

Yes, personally I prefer the more symmetrical buttons with less whitespace

On Thu, Sep 29, 2022, 9:21 AM cthorn2 @.***> wrote:

Let's pull it from the top. I have been asking for feedback on the designs, not from the group suggested, but coworkers/contacts. I've gotten some feedback that this design is preferred for the main menu. If you agree, I'll convert to Flutter/Dart and upload with the requested change.

[image: image] https://user-images.githubusercontent.com/111912838/193042565-d93bf730-588d-4b91-8025-6c7508ac5892.png

— Reply to this email directly, view it on GitHub https://github.com/umgc/fall2022/issues/399#issuecomment-1262274112, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7ECUQJWQKLRGM2VJ6TUILWAWJXNANCNFSM6AAAAAAQOLLLVY . You are receiving this because you were mentioned.Message ID: @.***>

[cthorn2]

Sounds good, I'll work on the updates today.

[cthorn2]

Just uploaded Update Main Menu page with 6 buttons and removed settings in top appBar. #504

[tatikozh]

I think Shane's mockup was looking very similar. Looks good! However, on the bigger devices (such as iPad) only 4 tiles are displayed and to access the other 2 you gotta scroll down. Doesn't affect semantics in any way.

[cthorn2]

Thanks, I'm looking into this now. However, I did not think we were supporting tablet devices or landscape mode. That adds a lot of additional complexity to the project. I currently working on fixing the evaluation of current screen size to expand/condense the tiles into a portrait layout of 2 columns by 3 rows in between the appBar and the bottomBar. It looks like iOS devices use a SafeArea so I'm looking into how that impacts Android too.

[tatikozh]

Just wanted to mention that. I'm planning to make some demo to show how it looks with semantics implemented and for iOS I have an iPad. Before we have this app in the TestFlight.

[cthorn2]

Ok, thanks for clarifying. I started sweating when I saw ipad and I thought I missed some UI elements with a lot more complexity.

[mdconatser]

I guess we didn't specifically state that in the scope that we aren't supporting tablets or landscape mode, but we could change that. I agree with not supporting landscape as many major apps don't, but I feel like tablet support may not be that bad. Still can exclude that from the scope too if it seems like too much work.

Also, I presume we should add all main functions still to the bottom bar ( at least Home / Search / Notifications / Settings / Chatbot), as that seems convenient. This would reintroduce the issue that Tatiana found, so we'll have to find a way to make them "not duplicates" or have one of them be excluded.

[tatikozh]

And speaking about the bottom bar, just a suggestion to not introduce the same issue we could have a different bottom bar on the main menu screen. Or have no bottom bar on the main menu screen at all (as most elements are duplicated anyway) and have just a floating Chatbot button, and the bar will be present on all other pages.

Also, I think that the Back button should redirect to the previous screen instead of Main Menu and the Home button shall be dedicated to the Main Menu page.