[feature] - add complementary role to VAlert
ontoneio opened this issue · 7 comments
Per WAI-ARIA Role=Complementary
I am have ran into a use case where there is a relevant piece of content that could be placed into a VAlert component, but is not necessarily needing the role="alert" semantics. It would be useful to be able to swap this for role="complementary" semantics.
For now, just binding directly overrides the `role="alert", so it's nothing but a feature, suggestion. I think it would be nice to give this flexibility though.
Nice. I'm thinking the best way to provide this is for the role to default to alert, and inherit the aria-role attribute if provided. That seems a pretty straight forward and intuitive approach. What do you think?
Well, say I have a use case where one piece of content is time sensitive and another is not. They both still are "alerting" folks to something, but accessibility wise, the semantics are presented differently. We cannot predict how a developer would like to implement that boolean type functionality, but we can be opinionated about the accessibility semantics.
So what would be your theoretical example? <VModal complementary>?
I was thinking <VAlert complementary /> but after meditating on it, I realized I could just use an <aside /> element as it comes with an implied role="complementary" from my understanding. So I think I can figure something out without this as I can see why it would get hairy.
Also, just want to say thank you for allowing me to work through some of this. I am still learning all the intentions of the library and I am enjoying working with it thus far. So if I make some more potentially unnecessary PR's, please forgive me. Closing this one.
Please dont think you are making unnecessary PRs. Having some help is very welcome, and Im sure that there a plenty of folks that know a lot more than I do.
I have reservations on adding things too quickly because once you add it, you cannot remove it without a breaking change. So if a solution can be found with the things available, we should use that. If it's an issue that is solved with better documentation, we should do that. And if it's something that needs to go into the lib, then we can do that.
The other thing worth mentioning is that Im slow to adopt accessibility changes because it's very hard to be 100% sure what the best approach is. So it's another area that is slower to be adopted into the project. As I've learned, not implementing a11y is better than implementing a11y poorly.
In closing, I am very grateful for any contributions, and if I seem slow to respond, it's not because I don't want help or think its a bad idea or whatever. I hope it doesn't come across that way.
Great to know, and thank you for the clarification. It certainly helps.
Just for the record, you have been a great collaborator. I think I am more worried about myself coming off as overly assertive.
I am working in a bit of a silo at my organization these days and don't get to work with many developers in this fashion (i.e Github, and the sort) even though I use Github myself. So I am still new and learning here how to be a productive collaborator on an OS project.
I am definitely going to be on the lookout for some patterns I can contribute to the Cookbook.
Thanks. I'm just figuring this stuff out as I go along as well.
Additions to the cookbook would be incredibly valuable. I think that is a big missing value-add for this project for the folks that want a bit more of a fully-implemented solution you would get with a different library like Vuetify.