Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[iOS][Accessibility ] [Focus is not going to the first accessibility element] #4890

Closed
jyoti-ms opened this issue Oct 7, 2020 · 10 comments · Fixed by #4944
Closed

[iOS][Accessibility ] [Focus is not going to the first accessibility element] #4890

jyoti-ms opened this issue Oct 7, 2020 · 10 comments · Fixed by #4944
Assignees
@jwoo-msft
Labels
Area-Accessibility Bugs around feature accessibility Area-Inconsistency Bugs around renderer inconsistencies across different platforms Bug High Priority Partner-MsftTeams Issues related to AC integration with Microsoft Teams partner Partner-MsftTeamsMobile Bugs related specifically to Teams Mobile integration (iOS/Android)
Milestone
20.10

Comments

@jyoti-ms
Copy link

jyoti-ms commented Oct 7, 2020 •
edited by jwoo-msft
Loading

Platform

What platform is your issue or question related to?

  • iOS

Author or host

Teams Mobile Client

Version of SDK

SDK version 2.1.0 (ACv1.3)

Details

When there are errors on the cards after pressing submit action, focus is not going to the first accessibility element (input field) on the card that has error message. Link to video
@jyoti-ms jyoti-ms added the Bug label Oct 7, 2020
@ghost ghost added this to the 20.10 milestone Oct 7, 2020
@ghost ghost added the Area-Inconsistency Bugs around renderer inconsistencies across different platforms label Oct 7, 2020
@ghost
Copy link

ghost commented Oct 7, 2020

please review this issue for target Milestone, Inconsistencies & Priority upon triage.

@shalinijoshi19 shalinijoshi19 added Partner-MsftTeamsMobile Bugs related specifically to Teams Mobile integration (iOS/Android) Partner-MsftTeams Issues related to AC integration with Microsoft Teams partner labels Oct 9, 2020
@ghost ghost removed the Triage-Needed label Oct 9, 2020
@ghost
Copy link

ghost commented Oct 9, 2020

Hi @jyoti-ms. We have acknowledged this issue report. Please continue to follow this issue for updates/progress/questions.

@ghost ghost added the Triage-Investigate label Oct 9, 2020
@shalinijoshi19
Copy link
Member

@jwoo-msft assigning to you for initial investigation. Pls update once we do have an action plan for this. Thanks

@shalinijoshi19 shalinijoshi19 added the Area-Accessibility Bugs around feature accessibility label Oct 9, 2020
@jwoo-msft jwoo-msft changed the title [iOS][Accessibility ] [Input Validation Errors] [iOS][Accessibility ] [Focus is not going to the first accessiblity element] Oct 12, 2020
@jwoo-msft jwoo-msft changed the title [iOS][Accessibility ] [Focus is not going to the first accessiblity element] [iOS][Accessibility ] [Focus is not going to the first accessibility element] Oct 12, 2020
@jwoo-msft
Copy link
Member

Hello @jyoti-ms,

Can you be more specific about what's the issue here? If there is an error, the focus will be set on the first input item with an error. For example, if it's input.text, the focus will be set on the input.text and open up a keyboard.

@ghost
Copy link

ghost commented Oct 12, 2020

Hello @jyoti-ms! We need some additional information from you to process this issue. Please see discussion comments above. Thanks!

@ghost ghost removed the Triage-Investigate label Oct 12, 2020
@jyoti-ms
Copy link
Author

@jwoo-msft When user clicks on submit button and if there is an error then, the view is getting scrolled and focus is not going to the first input that has errors.
Focus is going out of the adaptive card's view when voice over is on (on input validation).

This is happening whenever layout of the superview is changed due to errors.
Can you please take a look at the video once? Link to video Do let me know if you need more info on this.

@ghost
Copy link

ghost commented Oct 13, 2020

Thanks @jyoti-ms for following up on this issue. A member of our triage crew will re-engage as soon as possible to follow up. Thanks.

@jyoti-ms
Copy link
Author

jyoti-ms commented Oct 14, 2020 •
edited
Loading

@jwoo-msft This issue can be fixed only when action type is known to me on layout change notification.

Scenario - Currently layout change notification is sent to the host on button click(Action.ShowCard, Action.Submit, Action.ToggleVisibility). The host would need to have different layout change functions (teams client) based on the type of the action.
So if we have action.submit layout update call, then we can avoid performing reloadRows (because of this we are losing focus) we only need to update the height of the cell and changing the button state.
Can you please confirm on this if this is possible to provide action type and button ref on layout change notification?

Thanks!
cc:@sowrabh-msft @shalinijoshi19

@jwoo-msft jwoo-msft mentioned this issue Oct 21, 2020
Merged
@ghost
Copy link

ghost commented Oct 31, 2020

🎉This issue is now fixed by #4944 and successfully released as part of our AdaptiveCards@2020.10 offering.:tada:

Handy links:

@ghost
Copy link

ghost commented Oct 31, 2020

🎉AdaptiveCards@2020.10 has been released which fixes this issue.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jwoo-msft jwoo-msft

Labels
Area-Accessibility Bugs around feature accessibility Area-Inconsistency Bugs around renderer inconsistencies across different platforms Bug High Priority Partner-MsftTeams Issues related to AC integration with Microsoft Teams partner Partner-MsftTeamsMobile Bugs related specifically to Teams Mobile integration (iOS/Android)
Projects
None yet
Milestone
20.10
Development

Successfully merging a pull request may close this issue.

Updated layout notification to include properties microsoft/AdaptiveCards
3 participants
@jwoo-msft @shalinijoshi19 @jyoti-ms