5 ms·

Ask HN: I found opposition when improving the accessibility of the website

4 points by maury91 7y ago

I'm trying to improve the accessibility of the company's website. I created a merge request where I change the wrongly used attribute `role` into `data-role` to avoid the browser to misrepresent it. I also updated the Unit Test and End to End tests. A colleague is strongly opposing, and will not let me merge it until I find a customer that contacted the company because it's affected by this issue. What can I do?

thepapanoob 7y ago
i dont get what the issue is? this is a personal problem with your colleague
- maury91 7y ago
  the issue is that to solve the accessibility issue I need that a customer reports the problem.
onion2k 7y ago
Port the entire app in to React so you don't need to use attributes to store state. ;) More seriously, working with people who don't care about what they're building enough to want it to be a better product is hard. I don't really want to recommend that you resign and find a new job, but two decades of experience writing web software tells me that's probably the only real solution. If you're on a team with people who don't actively want the code to be as good as possible, and who are willing to put the effort in to making it that way, will be bad for your mental health and possibly bad for your career if you pick up that habit.
- maury91 7y ago
  the funny bit is the entire app is in React, and the attribute was leaking to the DOM, so to keep the unit tests and e2e tests work, I made the attribute go to the DOM as `data-role`. The attribute of the React component is still `role` so we can avoid a major refactoring.
uberman 7y ago
There are probably dozens of reasons both good and bad for preventing fly by night change requests. Some of them would depend on the size of your company. Is this the work the company wants you to do or are you off the on your own? Tossing aside the accessibility angle, fly by night changes often have ramifications that the authors did not anticipate. I have and would again veto change requests that not part of our planning process and offered as: "Surprise, here is this cool thing I did."
- maury91 7y ago
  however, his reason is none of them, his reason is "no one complained about it" other developers reviewed the change and have been tested to be sure we don't have regressions. The company is small, we are only 6 frontend devs.
  - uberman 7y ago
    Perhaps he is demonstrating that this type of behavior is not wanted. Was there a bug report or jira issue? If not, why are you using company resources on pet projects? I believe this is what he is telling you. You see that other devs have already reviewed the changes as a good thing. In my opinion this is the kiss of death for your case. Not only are you working on un-prioritized work but now others are as well. Work on stuff that has been prioritized. Don't get side tracked on work that has not been prioritized. If you believe it is important work, submit a bug report or feature request and get it prioritized. Then you can legit fix it and get it folded in. I know it seems petty, and I have been guilty of 'drive by refactoring" when I was a junior dev so I understand the temptation to "fix things".
    - maury91 7y ago
      This "bug" is a violation of the Equality Act, and so can have legal consequence if a customer reports it. This is the type of issues you want to fix before are reported, not after. It's like waiting for someone to die before adding a zebra crossing.

4 points by maury91 7y ago

thepapanoob 7y ago

i dont get what the issue is? this is a personal problem with your colleague

maury91 7y ago
the issue is that to solve the accessibility issue I need that a customer reports the problem.

onion2k 7y ago

Port the entire app in to React so you don't need to use attributes to store state. ;) More seriously, working with people who don't care about what they're building enough to want it to be a better product is hard. I don't really want to recommend that you resign and find a new job, but two decades of experience writing web software tells me that's probably the only real solution. If you're on a team with people who don't actively want the code to be as good as possible, and who are willing to put the effort in to making it that way, will be bad for your mental health and possibly bad for your career if you pick up that habit.

maury91 7y ago
the funny bit is the entire app is in React, and the attribute was leaking to the DOM, so to keep the unit tests and e2e tests work, I made the attribute go to the DOM as `data-role`. The attribute of the React component is still `role` so we can avoid a major refactoring.

uberman 7y ago

There are probably dozens of reasons both good and bad for preventing fly by night change requests. Some of them would depend on the size of your company. Is this the work the company wants you to do or are you off the on your own? Tossing aside the accessibility angle, fly by night changes often have ramifications that the authors did not anticipate. I have and would again veto change requests that not part of our planning process and offered as: "Surprise, here is this cool thing I did."

maury91 7y ago
however, his reason is none of them, his reason is "no one complained about it" other developers reviewed the change and have been tested to be sure we don't have regressions. The company is small, we are only 6 frontend devs.
- uberman 7y ago
  Perhaps he is demonstrating that this type of behavior is not wanted. Was there a bug report or jira issue? If not, why are you using company resources on pet projects? I believe this is what he is telling you. You see that other devs have already reviewed the changes as a good thing. In my opinion this is the kiss of death for your case. Not only are you working on un-prioritized work but now others are as well. Work on stuff that has been prioritized. Don't get side tracked on work that has not been prioritized. If you believe it is important work, submit a bug report or feature request and get it prioritized. Then you can legit fix it and get it folded in. I know it seems petty, and I have been guilty of 'drive by refactoring" when I was a junior dev so I understand the temptation to "fix things".
  - maury91 7y ago
    This "bug" is a violation of the Equality Act, and so can have legal consequence if a customer reports it. This is the type of issues you want to fix before are reported, not after. It's like waiting for someone to die before adding a zebra crossing.