
Ask HN: I found opposition when improving the accessibility of the website - maury91
I&#x27;m trying to improve the accessibility of the company&#x27;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.<p>A colleague is strongly opposing, and will not let me merge it until I find a customer that contacted the company because it&#x27;s affected by this issue.<p>What can I do?
======
onion2k
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
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
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
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
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
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.

~~~
uberman
So, you did not submit a bug or an enhancement request I take it. You
unilaterally decided that your code change was more important than the work
assigned to you by your company.

If it was/is _that_ important then you can create a ticket right?

~~~
maury91
the ticket exists and has been reviewed by a Product Owner, however, the other
dev doesn't accept it because it's not submitted by a customer

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

~~~
maury91
the issue is that to solve the accessibility issue I need that a customer
reports the problem.

