-
Notifications
You must be signed in to change notification settings - Fork 5
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
Pr/cdr 2153 refactor cdr input #39
Conversation
KenjiCrosland
commented
Mar 8, 2022
- Refactor CdrInput to use <script setup> syntax.
- Fixed v-model issue by referencing a new computed ‘inputModel’ with its own custom getter and setter.
- Ensured all fallthrough attributes except class get applied to the input element. The class attribute is bound to the outermost element.
- Added a uid module to provide a unique id for each component should an id not be provided by the user.
- Fixed some implementations issue on the CdrInput example page.
- Fixed a typo in CdrLabelStandalone.
…s with CdrInput. Add uids Refactor CdrInput to use <script setup> syntax. Fixed v-model issue by referencing a new computed ‘inputModel’ with its own custom getter and setter. Ensured all fallthrough attributes except class get applied to the input element. The class attribute is bound to the outermost element. Added a uid module to provide a unique id for each component should an id not be provided by the user. Fixed some implementations issue on the CdrInput example page. Fixed a typo in CdrLabelStandalone.
pulling this down to do some screen reader validation |
@@ -172,7 +172,7 @@ | |||
<span id="errorMessage">you have added too many characters, remove some</span> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AXE Dev tools is flagging how we use aria=errormessage
Fix the following:
aria-errormessage value undefined-error
must use a technique to announce the message (e.g., aria-live, aria-describedby, role=alert, etc.)
here is some additional context I tracked down
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. I fixed the undefined-error
. It looks like cdr-form-error
isn't structured so that the id
of the span containing the error message has the same value as aria-errormessage
on the input
element. Rather it's referencing the div containing the span. Is that ok or do we need the id to be on the element that contains the text node of the error message itself?
Was this test run via npm test
? I saw a11y tests pop up but I'm having chromedriver issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No I manually tested this in Axe dev tools - you may need a license for that still, if so we can reach out to Eric
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as if the id needs to be on the text node, https://rei.github.io/rei-cedar-docs/patterns/form-validation/#error-detection. I believe that it is fine on the containing wrapper though we can run some screen reader tests to be sure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it does looks like I need a license for Axe Dev Tools. Last time I used it it was free but rather clunky IIRC
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OH and this will need to be a unique ID, not "errormessage" but maybe {{input-lable}}-errormessage or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I fixed that. I got a trial account of axe and it looks like the issue isn't popping up anymore. The issue was twofold. I neglected to rename all instances of a variable (I need better refactoring extensions in vscode) and also there was an issue in the implementation of the form on the example page. Will double check after office hours
…ove tabindex from form error Removed ids from the spans slotted to the form error. These ids are automatically provided by the parent component. Remove tab-index=0 to form errors as form errors should not be tabbable.
Fixed issues with id mismatches which caused problems with axe and screenreaders. Also removed `aria-label=required` from cdr-label-standalone since this is superflous when the input is already labeled required
…tandalone snapshot
@@ -1,5 +1,5 @@ | |||
<template> | |||
<div :class="style[baseClass]" role="status" tabindex="0"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fixes the accessibility issue where the error was tabbable.
@@ -169,10 +169,10 @@ | |||
</template> | |||
|
|||
<template #error> | |||
<span id="errorMessage">you have added too many characters, remove some</span> | |||
<span>you have added too many characters, remove some</span> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This id is superfluous and is the cause of some axe accessibility issues.
@@ -8,7 +8,6 @@ | |||
{{ label }}{{ required || optional ? '' : '' }} | |||
<span | |||
v-if="required" | |||
aria-label="required" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aria-label="required"
is not needed here. Since the input element already has aria-required=true
all this does is make screen readers say "Required" twice.
More on this issue here: https://axe.deque.com/issues/20da7889-f026-402a-8886-3d5df7d2d83a
inheritAttrs: false, | ||
customOptions: {} | ||
} | ||
</script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, I was wondering when we might run in to needing to do this with the setup syntax