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.
That is interesting, do you have an example as I would love to hear about it, I find anything that is "bending to fit the rules not the goal" fascinating and helpful!
I can't send you a link because I work for an elected official and it would put a big 'ol target on our backs.
The basic problem is that it is forcing developers to provide exactly the same experience for sighted and non-sighted users. That's ridiculous. The experience will never be the same.
I'll start by saying - I was the advocate for accessibility on our team. I encourage everyone to write semantic code, make accessible tables and provide descriptive links and alt text.
To that end, the site is built like a table of contents. So every item in the top nav goes to a page with all the next level links. We also have drop-down mega menus with shortcuts to the most frequently used pages in the section. They are coded as nested lists. The mobile version does not have the menus, but you can still navigate to anywhere on the site.
It used to be that you could hover to open the menu then click in the same spot to go to the landing page. But no - that confuses the SR. The SR can still read and follow all the links in the menu, it just doesn't tell you when the menu is opened or closed. For some reason it's important for someone who can't see the screen to know whether the menu is open or not - even though the SR user can skip easily skip nested links that aren't relevant.
So we had to re-code, adding a bunch of aria - which tripled the amount of code needed for the menu - AND you can no longer just click on the nav bar to go to the next level - you have to mouse over to another link. So the site now has more code, more fragile code because of aria, slower download times, and its harder to use for the overwhelming percentage of users who do not use a screen reader - including those who have motor-skill issues. But it passes WCAG.
All this when the mobile version of the site is perfectly accessible to everyone as is. There should be a media query for screen readers. You could strip out all javascript and css. And if the HTML was coded correctly, it would be perfectly accessible.
Sorry for the long rant - I just find it frustrating that we went from the spirit of the law to the letter of the law.
I'll also point out that when we originally built all this in 2016-17 it passed WCAG1.0. Our code didn't change - the rules changed.
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.
It's not only confusing - it's regressive. We had to make our site less usable.
That is interesting, do you have an example as I would love to hear about it, I find anything that is "bending to fit the rules not the goal" fascinating and helpful!
I can't send you a link because I work for an elected official and it would put a big 'ol target on our backs.
The basic problem is that it is forcing developers to provide exactly the same experience for sighted and non-sighted users. That's ridiculous. The experience will never be the same.
I'll start by saying - I was the advocate for accessibility on our team. I encourage everyone to write semantic code, make accessible tables and provide descriptive links and alt text.
To that end, the site is built like a table of contents. So every item in the top nav goes to a page with all the next level links. We also have drop-down mega menus with shortcuts to the most frequently used pages in the section. They are coded as nested lists. The mobile version does not have the menus, but you can still navigate to anywhere on the site.
It used to be that you could hover to open the menu then click in the same spot to go to the landing page. But no - that confuses the SR. The SR can still read and follow all the links in the menu, it just doesn't tell you when the menu is opened or closed. For some reason it's important for someone who can't see the screen to know whether the menu is open or not - even though the SR user can skip easily skip nested links that aren't relevant.
So we had to re-code, adding a bunch of aria - which tripled the amount of code needed for the menu - AND you can no longer just click on the nav bar to go to the next level - you have to mouse over to another link. So the site now has more code, more fragile code because of aria, slower download times, and its harder to use for the overwhelming percentage of users who do not use a screen reader - including those who have motor-skill issues. But it passes WCAG.
All this when the mobile version of the site is perfectly accessible to everyone as is. There should be a media query for screen readers. You could strip out all javascript and css. And if the HTML was coded correctly, it would be perfectly accessible.
Sorry for the long rant - I just find it frustrating that we went from the spirit of the law to the letter of the law.
I'll also point out that when we originally built all this in 2016-17 it passed WCAG1.0. Our code didn't change - the rules changed.