Skip to content
This repository has been archived by the owner on Dec 8, 2022. It is now read-only.

Icon checkboxes missing text equivalent labels (1.1.1) #2234

Closed
Blackbaud-MattGregg opened this issue Dec 20, 2018 · 5 comments
Closed

Icon checkboxes missing text equivalent labels (1.1.1) #2234

Blackbaud-MattGregg opened this issue Dec 20, 2018 · 5 comments

Comments

@Blackbaud-MattGregg
Copy link
Contributor

Expected behavior

Labels are in the markup in the aria-label= property.

Actual behavior

The value in the TS file is not coming through in the markup produced (at least in the demo). The aria-label="" is blank.

Steps to reproduce

Go to https://developer.blackbaud.com/skyux/components/checkbox and inspect icon checkboxes

@Blackbaud-TrevorBurch
Copy link
Member

@Blackbaud-MattGregg looking into this I think this one is simply that our demo doesn't go far enough to show how things work. The label property is an input on checkboxes that sets what aria-label is set to. However, this property is an empty string by default so if nothing is passed in by the end user then aria-label ends up being set to nothing. (Which is what you are seeing).

If I'm understanding correctly we just need to update the demo to show how to use this property. Am I correct in that?

@Blackbaud-TrevorBurch Blackbaud-TrevorBurch self-assigned this Jan 9, 2019
@Blackbaud-MattGregg
Copy link
Contributor Author

@Blackbaud-TrevorBurch When I view this one in the demo and in Plunkr, the label values are being set in the JS class, but the aria-label="" is empty then in the HTML output.

@blackbaud-johnly This component doesn't seem to have any documentation of properties like the radio button?

@blackbaud-johnly
Copy link
Contributor

I created an issue to document the properties: #2258.

@Blackbaud-TrevorBurch
Copy link
Member

@Blackbaud-MattGregg I made blackbaud/skyux-forms#14 to address the empty attribute problem. All other places where we use the label input we do not set an empty string for the default; however, here we were and it was causing the attribute to show up when it shouldn't have. I verified that when a consumer sets the input that it shows up correctly.

@Blackbaud-TrevorBurch
Copy link
Member

Demo has been updated. Closing since we have a separate issue for the docs portion.

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

No branches or pull requests

4 participants