I'm not sure what implied I was offended. I responded to your points and asked direct questions.
I'm used to getting a lot of unsolicited feedback and love learning more about accessibility. However, that level of feedback would be intimidating for a lot of people, especially beginners to accessibility, who it would seem you want to help.
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 will chalk it up to a misunderstanding and phrasing issues between us both then! 👍 That is the problem with the written word!
So to answer your questions:-
point 1
Yeah that might not have been clear, I was referring to vanilla JS click handler which interprets Enter and Space as a click on a form control for you.
I am guessing React does actually treat onClick as just a mouse click or a tap on touch devices.
Looks like you found a solve for this one already though so it is all good 👍
Point 2
Nothing wrong with the animation, just how long it takes to show initially.
There is a perceivable delay between tabbing to the element and the outline starting to become visible, so I was just suggesting to see if you can address that if possible.
There are no other issues with the focus indicator as far as I can see!
Point 3
All good here, custom style sheets aren't that common, but they are used in maybe 3-5% (one of those made up statistics...but I did base it on experience 🤣) of accessibility requirements in the sense that people use a lot of plugins and browser extensions to manipulate the page to their preferences.
You are right, it isn't going to affect a large number of people, but the principle of visually hidden text vs same colour text (same colour text is really not a good idea as it can be selected by mistake and can take up space in the layout in other scenarios etc.) is a very good principle to learn for a lot of things and will get you out of a jam when fixing accessibility issues a lot of the time, so I thought it would make great practice.
Point 4
Association impairments are rare, but certain Visual Processing Impairments (the term to search for would be "Visual Processing Disorders") can have this effect (I wish I could remember the exact condition name, but it is eluding me).
I also worked with a young lad with autism and he said that this was something he sometimes struggled with (in fact he was where I got the church example from!), but yet again I would like to point out this is not common.
The "extra mile" part was a poorly phrased way of saying "If you don't mind changing the design slightly, a visible label is always preferable and should be added".
This yet again is a general principle that is really useful to remember as visible labels on forms help in loads of ways.
As for social icons and should you add a label on hover - ideally yes and on focus too.
But bear in mind that this point is that last 1% reaching for perfection, that was why I put "extra mile" as it really is covering every last item and the sort of thing that you would see on a WCAG AAA rated site (of which there are very very few!)
You could ignore this point, just remember visible labels are always better and that will serve you well when making decisions on labelling controls.
Wrapping up
All of the above are just good practices to try and learn early on.
They are things you will come across often (keyboard interactivity problems (common), animations that need adjusting (less common), text just for Assistive Tech (very common) and permanently visible labels (extremely common!).
Although it may seem like a lot of stuff to learn just for a toggle, the principles are some of the core things you will use often fixing accessibility so they are worth practicing and getting used to as it will make the rest of the work a lot easier.
Bonus thing to look at when you have capacity!
Look into prefers-color-scheme: light when you have the chance so the site goes into light mode if someone has set that preference in their browser / OS.
Everyone always talks about it for prefers-color-scheme: dark to switch on dark mode, but as your site starts in dark mode you want to approach it from the opposite angle.
This is really minor to be clear, but a great addition once you have done everything else and just something I thought I would throw in as something interesting!
Hope that all helps, any questions just ask! ❤
p.s. the fact you have written over 5000 words on accessibility is one of the reasons I reached out in the first place, I think it is fantastic! I also like the approach of telling it as a story of your journey and thought process, rather than as a guide / how to.
p.p.s. There is an article pinned in my profile "101 Digital Accessibility (a11y) tips and tricks" (4th one down), you may find it is a useful reference piece (and it is a reference piece...certainly not something to sit and read in one sitting as you will see if you read it 🤣).
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.
Thought you replied to this but it seems to have disappeared?
Anyway, I will just say the door is open if you do need anything, but I won't write an essay next time as we seem to have gotten off on the wrong foot because of it! 🤣
Followed you on Twitter so I don't miss the next article! ❤
Yeah, I wrote up why I still disagreed with many of your points but was advised that since it was factual and didn't match your tone, it seemed rude and I don't want to be rude.
For instance, my toggle does take into account user color mode preference using JavaScript instead of CSS - that's the part I refactored in this blog. However, I will take a look to see if the media query would add functionality.
I've incorporated the feedback I do agree with in the blog update yesterday or in the description of the Github issue I'll get to in the future.
Ultimately, I do still want to caution you against giving feedback this in-depth and pushing developers to be 100% perfect/WCAG AAA compliant without asking first. It's possible it might discourage people because perfect is often the enemy of good. Not to mention these issues often have more than one right answer. However, no one can say trying to make the internet more accessible one component at a time is a bad thing. 🙂
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.
Right, now we are on the same page there is one thing I will say then, don't worry about your responses to me appearing rude. I was more bothered about offending you so now we both agree that we aren't offended it is all good and I will certainly not be bothered by directness if that was the issue 😋
The disagreement on the toggle colour preference I think is just a misunderstanding then and might need a rephrase on my part!
prefers-color-scheme: light is purely for first time visitors, if their system setting is prefers light your site doesn't take it into account yet.
This is entirely different to storing the preference that they select, which works perfectly.
This really is a minor point, it was purely meant to be a point of interest, it is not a big issue and certainly doesn't need to be addressed right away.
If that is the bit that we are disagreeing on then just ignore this point and do it after everything else you have lined up on the site remediation plan!
That is if you even feel like doing it, it is not essential, just good UX!
As for the offering feedback, we are a million miles apart on that point, most of the people I am friends with on here started because of my essays and this is the first time I have had an even remotely negative response. With that being said your caution has been logged and heard! If I have a similar response in the future then I will take your caution into consideration!
If there were other points you want to discuss fire away, if not then I will wait for your next article and see what you tackle next!
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.
Hey InHu,
I'm not sure what implied I was offended. I responded to your points and asked direct questions.
I'm used to getting a lot of unsolicited feedback and love learning more about accessibility. However, that level of feedback would be intimidating for a lot of people, especially beginners to accessibility, who it would seem you want to help.
I will chalk it up to a misunderstanding and phrasing issues between us both then! 👍 That is the problem with the written word!
So to answer your questions:-
point 1
Yeah that might not have been clear, I was referring to vanilla JS
clickhandler which interprets Enter and Space as a click on a form control for you.I am guessing React does actually treat
onClickas just a mouse click or a tap on touch devices.Looks like you found a solve for this one already though so it is all good 👍
Point 2
Nothing wrong with the animation, just how long it takes to show initially.
There is a perceivable delay between tabbing to the element and the outline starting to become visible, so I was just suggesting to see if you can address that if possible.
There are no other issues with the focus indicator as far as I can see!
Point 3
All good here, custom style sheets aren't that common, but they are used in maybe 3-5% (one of those made up statistics...but I did base it on experience 🤣) of accessibility requirements in the sense that people use a lot of plugins and browser extensions to manipulate the page to their preferences.
You are right, it isn't going to affect a large number of people, but the principle of visually hidden text vs same colour text (same colour text is really not a good idea as it can be selected by mistake and can take up space in the layout in other scenarios etc.) is a very good principle to learn for a lot of things and will get you out of a jam when fixing accessibility issues a lot of the time, so I thought it would make great practice.
Point 4
Association impairments are rare, but certain Visual Processing Impairments (the term to search for would be "Visual Processing Disorders") can have this effect (I wish I could remember the exact condition name, but it is eluding me).
I also worked with a young lad with autism and he said that this was something he sometimes struggled with (in fact he was where I got the church example from!), but yet again I would like to point out this is not common.
The "extra mile" part was a poorly phrased way of saying "If you don't mind changing the design slightly, a visible label is always preferable and should be added".
This yet again is a general principle that is really useful to remember as visible labels on forms help in loads of ways.
As for social icons and should you add a label on hover - ideally yes and on focus too.
But bear in mind that this point is that last 1% reaching for perfection, that was why I put "extra mile" as it really is covering every last item and the sort of thing that you would see on a WCAG AAA rated site (of which there are very very few!)
You could ignore this point, just remember visible labels are always better and that will serve you well when making decisions on labelling controls.
Wrapping up
All of the above are just good practices to try and learn early on.
They are things you will come across often (keyboard interactivity problems (common), animations that need adjusting (less common), text just for Assistive Tech (very common) and permanently visible labels (extremely common!).
Although it may seem like a lot of stuff to learn just for a toggle, the principles are some of the core things you will use often fixing accessibility so they are worth practicing and getting used to as it will make the rest of the work a lot easier.
Bonus thing to look at when you have capacity!
Look into
prefers-color-scheme: lightwhen you have the chance so the site goes into light mode if someone has set that preference in their browser / OS.Everyone always talks about it for
prefers-color-scheme: darkto switch on dark mode, but as your site starts in dark mode you want to approach it from the opposite angle.This is really minor to be clear, but a great addition once you have done everything else and just something I thought I would throw in as something interesting!
Hope that all helps, any questions just ask! ❤
p.s. the fact you have written over 5000 words on accessibility is one of the reasons I reached out in the first place, I think it is fantastic! I also like the approach of telling it as a story of your journey and thought process, rather than as a guide / how to.
p.p.s. There is an article pinned in my profile "101 Digital Accessibility (a11y) tips and tricks" (4th one down), you may find it is a useful reference piece (and it is a reference piece...certainly not something to sit and read in one sitting as you will see if you read it 🤣).
Thought you replied to this but it seems to have disappeared?
Anyway, I will just say the door is open if you do need anything, but I won't write an essay next time as we seem to have gotten off on the wrong foot because of it! 🤣
Followed you on Twitter so I don't miss the next article! ❤
Hey InHu,
Yeah, I wrote up why I still disagreed with many of your points but was advised that since it was factual and didn't match your tone, it seemed rude and I don't want to be rude.
For instance, my toggle does take into account user color mode preference using JavaScript instead of CSS - that's the part I refactored in this blog. However, I will take a look to see if the media query would add functionality.
I've incorporated the feedback I do agree with in the blog update yesterday or in the description of the Github issue I'll get to in the future.
Ultimately, I do still want to caution you against giving feedback this in-depth and pushing developers to be 100% perfect/WCAG AAA compliant without asking first. It's possible it might discourage people because perfect is often the enemy of good. Not to mention these issues often have more than one right answer. However, no one can say trying to make the internet more accessible one component at a time is a bad thing. 🙂
Right, now we are on the same page there is one thing I will say then, don't worry about your responses to me appearing rude. I was more bothered about offending you so now we both agree that we aren't offended it is all good and I will certainly not be bothered by directness if that was the issue 😋
The disagreement on the toggle colour preference I think is just a misunderstanding then and might need a rephrase on my part!
prefers-color-scheme: lightis purely for first time visitors, if their system setting is prefers light your site doesn't take it into account yet.This is entirely different to storing the preference that they select, which works perfectly.
This really is a minor point, it was purely meant to be a point of interest, it is not a big issue and certainly doesn't need to be addressed right away.
If that is the bit that we are disagreeing on then just ignore this point and do it after everything else you have lined up on the site remediation plan!
That is if you even feel like doing it, it is not essential, just good UX!
As for the offering feedback, we are a million miles apart on that point, most of the people I am friends with on here started because of my essays and this is the first time I have had an even remotely negative response. With that being said your caution has been logged and heard! If I have a similar response in the future then I will take your caution into consideration!
If there were other points you want to discuss fire away, if not then I will wait for your next article and see what you tackle next!
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!