Styling libraries may be contributing to this issue. Whenever I use a styling library, they require anchor tags to be used as buttons. Its a bit annoying and I could just write the styles for a button tag but that slow things down. The problem is not writing the same styles for a button tag, but making sure the styling library works with your button element. And also making sure css features work on older browsers, which means the developer needs to do a bit of homework to make sure the styling is compatible across multiple platforms. And don’t forget that all task have a deadline, would risk missing a deadline for a anchor tag?
After styling has been corrected to use button elements instead of anchor. How do we make sure the next developer is aware of the changes? Is there a internal documentation for styling library or will they use the documentation on the styling library’s site?
I guess things would be better if we could get all the rant guys to build a styling library and maintain. Because they are as many libraries for styling compared to programming libraries.
I do agree on just getting rid of IE all together!
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.
As I said libraries and tutorials are one of the biggest offenders and I do kind of get where you are coming from.
However that is a poor excuse really.
Add the CSS so a <button> can be styled correctly.
Find every <a href="#" in the project, replace with a <button> - might take half a day on a gigantic project even if you do it manually (and if it is that large there will be a large dev team so you can give this job to a junior dev as a nice lesson in why accessibility first thinking saves a load of headaches!)
Update internal guides - depends how well maintained they are in the first place I guess.
At the most you are talking a day or two and that would be on something monstrous.
If your company got sued under the ADA (over 3500 cases last year) - "it was the library we use" would not hold up in court!
The above is still a little bit of the angry man having fun:
I am also a realist, I know the things you mention are real problems and I am dumbing them down.
What I am really saying is just fix it going forward, make better decisions when choosing libraries and frameworks. Put accessibility on the table and say "we have a problem here, how can we fix this as part of ongoing maintenance, how can we fix it going forward" - often it is really simple and just involves understanding why it is a problem (point them to my angry man rant if you want 🤣) and everything falls into place.
And if there is a little resource doing mundane things like adjusting the shade of blue used on page X - perhaps get them to fix a couple of anchors to buttons instead!
Baby steps!
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.
Styling libraries may be contributing to this issue. Whenever I use a styling library, they require anchor tags to be used as buttons. Its a bit annoying and I could just write the styles for a button tag but that slow things down. The problem is not writing the same styles for a button tag, but making sure the styling library works with your button element. And also making sure css features work on older browsers, which means the developer needs to do a bit of homework to make sure the styling is compatible across multiple platforms. And don’t forget that all task have a deadline, would risk missing a deadline for a anchor tag?
After styling has been corrected to use button elements instead of anchor. How do we make sure the next developer is aware of the changes? Is there a internal documentation for styling library or will they use the documentation on the styling library’s site?
I guess things would be better if we could get all the rant guys to build a styling library and maintain. Because they are as many libraries for styling compared to programming libraries.
I do agree on just getting rid of IE all together!
As I said libraries and tutorials are one of the biggest offenders and I do kind of get where you are coming from.
However that is a poor excuse really.
<button>can be styled correctly.<a href="#"in the project, replace with a<button>- might take half a day on a gigantic project even if you do it manually (and if it is that large there will be a large dev team so you can give this job to a junior dev as a nice lesson in why accessibility first thinking saves a load of headaches!)At the most you are talking a day or two and that would be on something monstrous.
If your company got sued under the ADA (over 3500 cases last year) - "it was the library we use" would not hold up in court!
The above is still a little bit of the angry man having fun:
I am also a realist, I know the things you mention are real problems and I am dumbing them down.
What I am really saying is just fix it going forward, make better decisions when choosing libraries and frameworks. Put accessibility on the table and say "we have a problem here, how can we fix this as part of ongoing maintenance, how can we fix it going forward" - often it is really simple and just involves understanding why it is a problem (point them to my angry man rant if you want 🤣) and everything falls into place.
And if there is a little resource doing mundane things like adjusting the shade of blue used on page X - perhaps get them to fix a couple of anchors to buttons instead!
Baby steps!