My JS pulls the mode set in their browser's localStorage on load whether or not they've clicked on the toggle and then matches in the toggle and on the page, which I was under the impression would be set by something like that. It'll be interesting to see if I can incorporate the CSS check easily.
Yeah, I just encourage a lot of very new devs to write and a formatted 4 point list is a lot! Plus, even the experts I've heard advise against going for 100% right off the bat because it would be overwhelming, but I understand that this was not solely in the context of me doing a whole overview of my site, just this component. Wasn't meant to be negative, just factual and quick. I have heard the the tone matching message now. 😅
I think React's onClick is the equivalent of writing an event handler like click. I think it's <button> that works on Enter and Space and click automatically.
It's not that I don't know the general concepts or want to spend time on things, and I have been practicing since the moment I picked up HTML, but I don't see enough evidence to spend time on user style sheets and am going to lump in making sure the toggle is obvious to cognitively impaired users with my final screenreader tests/that Github issue. Plus, as a developer, I need to spend my limited time on issues that will make the most impact during a big audit fix like this.
I think a label on focus/hover should be sufficient for the extraneous color mode toggle that's not a form and am willing to accept if that makes it just a tad bit less accessible for my pretty design. 😭
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
I think React's onClick is the equivalent of writing an event handler like click. I think it's that works on Enter and Space and click automatically.
Yeah sorry I made a complete hash of that...trying to explain what I was thinking would be more confusing than me just saying "it is fine as it is, ignore me" so I will just say that! 🤣
And as for the points I raised, you are right, they are not important now, just add them to the list!
I think the last thing I should perhaps have clarified earlier on to save us both a lot of too and fro is that the current design is accessible to a stage where it is better than 95%+ of dark mode toggle switches out there! It certainly is good enough, it is production ready, it would pass an audit(see "NECESSARY CAVEAT") and in fact it is more than good enough it is great!
The changes I suggested will not affect WCAG in any way or affect an audit either, they are good practices not compliance points. (WCAG is far from all encompassing).
I think a label on focus/hover should be sufficient for the extraneous color mode toggle that's not a form and am willing to accept if that makes it just a tad bit less accessible for my pretty design. 😭
It certainly is, there is knowing the ideal and working to constraints, it is a fair compromise (I am not militant even if it seemed like it, knowing when you can "cut a corner" and still be accessible is part of the game and what makes accessibility fun!)
NECESSARY CAVEAT - Really prickly auditors might say the lightmode version of the toggle does not have contrast of 3:1 with it's surroundings under SC 1.4.1 Non Text Contrast...if they did say that in a report and given the control design using multiple colours etc. I would call them a **** ****** for being picky, but I can't say it would defo pass without pointing that out!
Ooooh I will check out the color contrast because I am militant about that. 😂 I'm not sure any of the automatic tools caught it, but I'll have to doublecheck.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
I don't think automated tools would catch it as you are styling the label rather than the control, the tools are pretty dumb when you start using fancy tricks!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My JS pulls the mode set in their browser's localStorage on load whether or not they've clicked on the toggle and then matches in the toggle and on the page, which I was under the impression would be set by something like that. It'll be interesting to see if I can incorporate the CSS check easily.
Yeah, I just encourage a lot of very new devs to write and a formatted 4 point list is a lot! Plus, even the experts I've heard advise against going for 100% right off the bat because it would be overwhelming, but I understand that this was not solely in the context of me doing a whole overview of my site, just this component. Wasn't meant to be negative, just factual and quick. I have heard the the tone matching message now. 😅
I think React's
onClickis the equivalent of writing an event handler likeclick. I think it's<button>that works on Enter and Space and click automatically.It's not that I don't know the general concepts or want to spend time on things, and I have been practicing since the moment I picked up HTML, but I don't see enough evidence to spend time on user style sheets and am going to lump in making sure the toggle is obvious to cognitively impaired users with my final screenreader tests/that Github issue. Plus, as a developer, I need to spend my limited time on issues that will make the most impact during a big audit fix like this.
I think a label on focus/hover should be sufficient for the extraneous color mode toggle that's not a form and am willing to accept if that makes it just a tad bit less accessible for my pretty design. 😭
Yeah sorry I made a complete hash of that...trying to explain what I was thinking would be more confusing than me just saying "it is fine as it is, ignore me" so I will just say that! 🤣
And as for the points I raised, you are right, they are not important now, just add them to the list!
I think the last thing I should perhaps have clarified earlier on to save us both a lot of too and fro is that the current design is accessible to a stage where it is better than 95%+ of dark mode toggle switches out there! It certainly is good enough, it is production ready, it would pass an audit(see "NECESSARY CAVEAT") and in fact it is more than good enough it is great!
The changes I suggested will not affect WCAG in any way or affect an audit either, they are good practices not compliance points. (WCAG is far from all encompassing).
It certainly is, there is knowing the ideal and working to constraints, it is a fair compromise (I am not militant even if it seemed like it, knowing when you can "cut a corner" and still be accessible is part of the game and what makes accessibility fun!)
NECESSARY CAVEAT - Really prickly auditors might say the lightmode version of the toggle does not have contrast of 3:1 with it's surroundings under SC 1.4.1 Non Text Contrast...if they did say that in a report and given the control design using multiple colours etc. I would call them a **** ****** for being picky, but I can't say it would defo pass without pointing that out!
Ooooh I will check out the color contrast because I am militant about that. 😂 I'm not sure any of the automatic tools caught it, but I'll have to doublecheck.
I don't think automated tools would catch it as you are styling the label rather than the control, the tools are pretty dumb when you start using fancy tricks!