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.

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

Accessibility: Reflects text input behaviors #103

Open
KmBarnett opened this issue Oct 18, 2023 · 5 comments
Open

Accessibility: Reflects text input behaviors #103

KmBarnett opened this issue Oct 18, 2023 · 5 comments

Comments

@KmBarnett
Copy link

KmBarnett commented Oct 18, 2023

Hey, I work for a large company, and our accessibility team suggested that this component act more like a single input because it captures one value. I tried to write their comments as users stories sorry if they are bad

As a user, when I tab to the input, I will see my cursor on the first box that is not filled.

  • Ex: There are five characters total. I have filled out positions 1 and 2; tabbing to the input would take me to the 3rd inbox

As a user, when Focus is given to the CodeInput, a screen reader would read the associated label, and not as the focus moves between the box fields.

As a user, when the CodeInput is focused, and I press the left and right arrow keys, the focus moves to the correct box and reads out the current value.

@AlexMiniApps
Copy link
Owner

@KmBarnett Hello, thank you for the feedback. Actually I don't understand exactly what is wrong currently with the component.
Could you please describe the required behavior? Maybe do you have some screens?

@KmBarnett
Copy link
Author

KmBarnett commented Oct 19, 2023

@AlexMiniApps According to our accessibility guy, your component replaces one input with one per character/digit. To give a keyboard user the same experience as an input, the component would need to behave like a regular input. Unfortunately, I do not know how to show screens to display the way a screen reader interacts with your component, so the best feedback I can give follows

  • One tab stop for the entire input
  • Ability to have one label for the entire input
  • Ability to use arrow keys to move between characters/digits

@AlexMiniApps
Copy link
Owner

@KmBarnett ok, I will research.

@Thomas-Schindler
Copy link

Hello,

I'm using the library for implementing a two-factor authentication with a mobile authenticator app. Actually I found it very easy to integrate in our Angular 16 application. But as @KmBarnett pointed out, there are some accessibility issues which need to be addressed, otherwise our UX architect will block the usage for the component. :-(

@KmBarnett From what I've seen, there you can tab between the single input fields, so I don't know if it is form an a11y point of view necessary to implement the ability to use the arrow keys.

@AlexMiniApps If checked the outcome in my Firefox browser with the axe development tool and there are critical issues concerning the input component for each digit/character:

Form elements must have labels
To solve this problem, you need to fix at least (1) of the following:

  • Form element does not have an implicit (wrapped) <label>
    
  • Form element does not have an explicit <label>
    
  • aria-label attribute does not exist or is empty
    
  • aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
    
  • Element has no title attribute
    
  • Element has no placeholder attribute
    
  • Element's default semantics were not overridden with role="none" or role="presentation"
    

I would suggest to add an "aria-label" attribute to each input field withe a value like "code input number +", maybe it would be possible to enhance the component API with an input value "inputLabelTemplate" which is then extended by the index of the input field. That way the user could define a fitting input label like "Authenticate Code Digit Number", which will be extended with the field index for each input element.

Would that be a feasible solution?

@AlexMiniApps
Copy link
Owner

@Thomas-Schindler Thanks for the feedback, I understand your point. I will think about the implementation. Maybe there will be an array of strings per each input instead of the single string inputLabelTemplate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants