search

AmpleOrganics / Blaze.vue

Ample Organics Component Library
https://blaze-vue.netlify.com
MIT License
6 stars 2 forks source link

new feature on accessibility for radio label #416

Closed andystu closed 3 years ago

andystu commented 3 years ago

https://akerna.atlassian.net/browse/HM-251

input radio elements must have labels.

Screen Shot 2021-02-04 at 2 39 15 PM

bobmanary commented 3 years ago

image This is the yarn serve docs page. The input already had a label, there are now two copies of the label text in the document, and clicking on the visible label no longer toggles the radio. I'm not sure that this change is necessary or improves accesssibility.

bobmanary commented 3 years ago

Extending the blaze radio component might not be the best path for addressing the specific table row example listed in HM-251. For custom controls like that, the application should implement the most appropriate accessibility features itself rather than increase this generic component's complexity or reduce its accessibility/usability for the majority of other non-table uses.

andystu commented 3 years ago

image This is the yarn serve docs page. The input already had a label, there are now two copies of the label text in the document, and clicking on the visible label no longer toggles the radio. I'm not sure that this change is necessary or improves accesssibility.

thanks for bring this good point, the original label for current component was not passed by accessibility test when toggle it off. Even the example in here shows that it is ok to put label around radio input. https://www.w3.org/wiki/Html/Elements/input/radio

But following reference shows label tag should be put before or after radio input. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/radio https://www.w3.org/WAI/tutorials/forms/grouping/ So follow refs and made changes and put a css trick here to avoid conflict of original label showing, the accessibility test for radio input label was passed.

bobmanary commented 3 years ago

I don't believe this component should attempt to handle "no label" accessibility; that should be implemented by the application itself using a non-Blaze input element and id/for labels or aria attributes as necessary. Either way, this PR makes the current component less usable in normal situations by removing the larger click target that a real label element provides.

andystu commented 3 years ago

should try other way to improve accessibility for HM-251.