Chromebook accessibility: Changing the order of mouse buttons is unsupported
shkspr.mobi
shkspr.mobi
In a similar way to saying a subtitled movie isn't acessible. Sure, it meets the needs of the Deaf community - but not people with low/no vision.
Google have done some great things in accessibility - and I regularly work with them. But this specific issue has remained unresolved for too long now.
Those were from before this blog post (most recent was December). Sounds like the problem is prioritization, not convincing them it's a good idea.
Is accessibility generally treated in such a binary sense? If something isn't accessible to everyone, it isn't accessible? (Genuine question. Either answer would be valid. I'd prefer to know how it's used in common parlance.)
It's not, otherwise closed captioned videos wouldn't be released without audio description tracks (and vice versa).
If you look at, for example, the WCAG rules on accessibility, you'll see that there are various levels of conformance. Accessibility isn't just about blind people, or deaf people, or people with tremors, or people with cognative impairments. It is about all of us. You and me.
One day, you will be old. Your eyes won't be as good as they were and your joints will be stiff. Then someone will tell you that Windows 2038 is accessible because it is voice controlled. That's nice for you, but not much help for someone who has lost their voice.
Sorry, I'm rambling. Accessibility means including everyone.
(disclaimer: that this does not mean I think an effort should not even be made. But there will always be outliers as that is the painful reality we live in. I do think OP is justified in their complaint and wanting more accessibility. But I don't think it is their "right" to expect that demand to be met)
In some places, a wheelchair bound person can't access half of buildings, or rooms (important ones like toilets) within buildings. The streets themselves and transport can have access barriers like stairs.
In some other places, building codes/rules demand that even private homes are accessible. To an individual, this can be frustrating. Why are they forced to build a ramp using their space and their money? No one they know even uses a wheelchair. Is all this for that one time in 12 years when someone needs it?
I don't know the answers, personally, nor do I have serious opinions about how all this should be handled. However... I do think that if you are making an argument for wheelchair ramps as standard building code, you have to be making that argument at the city/society level.... the needs of all wheelchair people to access all buildings/places in a city. You can't reason about it via a single ramp and its users or lack thereof.
Obviously, it never gets to 100%. But, it does get pretty good. Compare many types of accessibility now to 20 or 50 years ago... acheivements have been achieved, with real impact on people's lives.
Most new ATMs are installed at a low height. That's great for wheelchair users, but it's a serious problem for taller people with spinal problems.
Accessibility is frequently a compromise between different user groups. In this case, the extra functionality that you require would add complexity to the UI and the underlying code base - complexity that may constitute an accessibility impediment for other user groups.
You can use Ubuntu and map whatever you like to whatever else you like. My elderly grandparents can't use Ubuntu, because the interface is too complex. UI quirks that you or I wouldn't notice are hard roadblocks for people with cognition and memory impairments. Simplicity, reliability and consistency are accessibility features.
The issue tracker discussion seems reasonable to me. The UI team don't want to add and support the code necessary to facilitate the multitude of requests for remapping and shortcuts, so would prefer a suitable API for extensions. The kernel team have serious security concerns about such an API, because it would effectively permit keyloggers on the Chrome OS platform.
On a practical level, I'd advise OP to install Crouton.
Broadly speaking, you can go with a minimalist system or a powerful one. It's easier easier to make minimalist simple & intuitive with great defaults. The other option is powerful, where the system can do lots of things. Linux is powerful. Lots of exceptions, but the rule is trade-off.
Accessibility is, almost by definition, suitability for rare-ish use cases. Rarity varies. Some people need a thumb mouse. Some need color schemes. Some need to operate a machine using only their eyes. Accessibility is, also almost by definition, achieved by adding optional features... A choice further along the "powerful & complex" end of the spectrum will tend to work better for a diverse accessibility goalset.
"Simple yet powerful" is a design goal specifically because it is paradoxical.... like "light yet strong" or "affordable luxury." It means you made your trade-offs and have come out ahead.
... And so nothing gets done.
After encountering a few issues like this, it's why I no longer use Chrome on any device. I understand the Chrome team is incredibly busy. But especially on Chrome UX matters, user_request > UX_rejection > API_request > /dev/null seems an annoyingly common outcome.
It is a bug if it excludes disabled people.
Fortunately not everyone is forced to use Chrome.
Considering the adoption of Chromebooks in government and public education spaces, Section 508 might disagree.
I'm not a 508 expert, though. I pulled up the spec and though there isn't anything specific about remapping buttons on mice, I did find this:
> 502.3.13 Modification of Focus Cursor. Focus, text insertion point, and selection attributes that can be set by the user shall be capable of being set programmatically, including through the use of assistive technology.
It would seem, then, that the actual buttons mapped for accomplishing the above MUST be modifiable or remappable for 508 compliance.
But I'm probably wrong. Someone check me on it:
https://www.access-board.gov/guidelines-and-standards/commun...
---
Edit: commented directly on the feature thread. https://bugs.chromium.org/p/chromium/issues/detail?id=221914...
Remapping buttons should be trivial. Changing the colors of the UI should be trivial. Accessibility should be trivial! It is 2019 FFS. Why have we allowed software to regress so much as an industry? What is wrong with us?
If you want a computer, get a computer. If you want a cheap Google ad-viewing portal, get a Chromebook.
Standard ChromeOS shows 0 additional ads compared to standard Chrome on Windows 10 or even Firefox on Windows 10 without an ad blocker.
In fact both Ubuntu and Windows 10 do, or have shown ads outside of the browser, so IMO they have _more_ ads then chrome os does. Nothing stops you from putting an ad blocker on Chrome OS too.
That said chrome os isn't for everyone, but I would not call it a "Google ad-viewing portal" what so ever. That suggests it's like the kindle fires with their ads which isn't the case.
Look, I get that there are some jackasses out there, but I think it's really wrong to use the words "open source dev" as an insult. People are out there giving their time and talents to the world for free, and we're all better off for it. An imperfect volunteer still deserves a thank you, not public ridicule.
The community has an image problem and that is definitely a problem for the entire community. You can try and say "well, most of them aren't like that", but it just doesn't matter because enough of them are and it is an accepted part of the culture.
Frankly, I don't care if you worked for free. That's a fair reason for not giving enough of a crap to fix something, but at the same time you'd better not be holding that mentality while trying to recruit me as a user. If I can't use your software then I don't see a reason to thank you for making it.
Frankly, a lot of users really do have bad workflows, questionable use-cases and they are relatively uninformed and often unwilling to learn why things work the way they do. If they don't pay, what else should they do besides fixing it themselves?
Generally though, "patches welcome" or "fix it yourself" is just a more polite way of saying "this is getting annoying, please leave now". I don't think those developers actually care that you (don't) use their software. You can tell when somebody actively wants to keep you as a user by them not acting in that way. Like saying "we'll consider it" and then proceeding to do nothing, for example.
>Frankly, a lot of users really do have bad workflows, questionable use-cases and they are relatively uninformed and often unwilling to learn why things work the way they do.
Yes, everyone thinks this about everyone else's workflow. Part of being a good developer, I think, is that just because you can't understand why someone wants to do a certain thing doesn't mean that their use case is invalid. That's childish and, frankly, entirely expected of Open Source Dev culture, which has a nasty habit of being condescending to users.
For all intents and purposes, if you fail to make a convincing argument for a use-case to a developer, it is invalid. It's not actionable. An argument could be made for any program to do anything in any possible way, for any number of reasons. Developers need to narrow that possibility space down radically. It would be nice if developers could spend the time really understanding every opinion offered to them, but it's not going to happen.
> That's childish and, frankly, entirely expected of Open Source Dev culture, which has a nasty habit of being condescending to users.
Doing "customer support" for free to the general public can wear on you. In fairness, can we agree that there are "difficult users" as well?
There's a difference between failing to make a convincing argument and the developer willfully refusing to understand the usecase because they do things differently and are arrogant enough to believe that their way must be "the one true right way". That's the problem that plagues open source devs.
> Doing "customer support" for free to the general public can wear on you. In fairness, can we agree that there are "difficult users" as well?
Of course there are difficult users, that's not what I'm talking about. The use-case asked for by the OP is not even remotely unreasonable, yet nothing was done for 5 years even though it should be trivial. It's just remapping buttons FFS. Instead they were dismissed as an "edge case" and the functionality as something only "power users" would want, and therefore they didn't have to lift a finger. I wish I could say I was surprised, but that's what I've come to expect from modern developers. Users are cattle, best not to anthropomorphize them.
Nobodies like you, who have no name, who have a disposable identity, who get to accuse people of misdemeanor online. You are not a decent person, that's for sure.
> No. The message being put out is that Google doesn't want unhealthy people using its products.
This upsets me because I know a lot of devs do care about accessibility. Hell, it's not even about developers, any decent human would want to help out someone when they can. To just say that google employees don't care because they're "young and healthy" is unwarranted and frankly quite rude.
And, yes, I am being rude. I am in pain and it sucks. I've tried being polite for five years and the bug hasn't got any significant attention. Now it has.
And your first example doesn't even mention that there is a specially designed high-contrast mode for android which fixes the readability issues for those who need it, and Chrome has a text scaling option which can increase the font size and will actually wrap in the way you want, and android itself has a "large text mode" which will achieve much of the same.
Google isn't perfect, but those examples aren't exactly doing you any favors trying to show the issues.
Many of the comments in the bug you linked in the original blog post are just about people with extra buttons they want to use. It doesn't seem like an accessibility motive for fixing it was figured out until just this past November.
That's like me writing an operating system right now, from zero and OP downloads it and feels left-out that I do not have support for re-assigning mouse buttons. What if I wrote an OS specifically for power users with no disability because I'm targeting that exact group? Or an OS that only works with gamepads (I am exaggerating here). Should I feel bad because people who can't use gamepads want to use it even tough it is not made for them specifically?
To me, a person with no disabilities and that does not know what you're going through, it feels like this: I'm way to tall to fit in a Disney World ride and instead of going for another ride I could fit in I complain that they discriminate against me and demand they make changes specifically for my tallness.
Or due to my physical condition (way to tall and a bit overweight) I can't make it as an astronaut for Nasa's next mission since I don't fit in the capsule and I demand they compensate for my extra kg's and need of space inside the capsule instead of choosing someone that fits their current capsule.
I'm not being ignorant of your problem I'm just trying to understand how the dev team behind ChromeOS is responsible for all the edge-cases out there. I'd see it as a problem if they were designing an OS specifically for people with disabilities.
However, as other have said, adding just one feature isn't too bad, but 1000 people wanting just one feature becomes unmanageable, and ChromeOS is intentionally slim.
There are mice with built in profiles such as the Razer and Logitech series that can switch the mice buttons (and have a button to toggle the profile). They aren't crazy expensive either, the logitech one is ~30$ IIRC.
Seriously?
It's just a product that is intentionally stripped down & doesn't cover all edge cases.
There are thousands of unhealthy people who are being deliberately excluded from Google's cheap computing revolution. How many of us do there need to be before we're not an edge case?
Remove the word deliberately and you've got the truth. It's not like they sat around the boardroom and said: "You know what, let's make our computers only usable by healthy folk". It just happened, Google has a ton of people who didn't think about this aspect. It wasn't something they planned or even thought about.
That's because key mapping and button mapping is more or less the same problem, as far as computers are concerned.
From the blog: "Evoluent - the manufacturer of my mouse - also provide a handy tool for Windows and Mac so that I can set the mouse buttons up just the way I like them".
There's a technical reason for that (actually, two): USB HID allows devices to expose how many buttons they have, plus some characteristics, but it's utterly useless to expose the information that "button 17 is the one in the top right corner when seen from above". The other reason is that USB device vendors (no matter which device type) don't feel the need to implement standards faithfully, so devices need special handling in drivers all the time.
So Evoluent provides its own Windows and Mac tool. In the bug linked in the post, the devs are discussing adding such special cases, or - instead, and preferred - providing an API through which third parties (no matter if Evoluent or that chap who can write xinput configs) could develop frontends that could do such configuration.
Now, these APIs shouldn't enable third parties to essentially log everything entered by the user. And that's where the discussion is at.
I'm not sure if the Evoluent tool reconfigures the device (through some proprietary vendor commands to the mouse) or reconfigures Windows to remap these buttons.
Interestingly the former case might already be supportable on Chrome OS, since it supports the WebUSB APIs. Since these USB commands would be non-standard and most likely undocumented by the hardware vendor, it would be up to Evoluent to provide such a frontend to configure the device.
The latter case (configuring a remapping) would be similar to that API that is under discussion. It doesn't go as fast as the blog post's author wants, okay. But screaming into the void (or even here) doesn't help with advancing that process.
Yes, they admitted it wasn't for power users. Needing to click with your thumb instead of your finger isn't a power user feature, it's an accessibility feature. That's why everyone is complaining about it.
They made a conscious choice not to add power user features. They did not make a conscious choice not to add accessibility feature, it was just a knock on effect. Hence it not being deliberate.
I agree. The "power user" requirement here would be: needing to override/remap this behaviour in the OS, as opposed to having a specialist device with different buttons
Calling someone with a disability a power user... grates.
There's a big difference between my productivity-enhancing .vimrc and not being able to use something. Half the devs seem to understand this.
Either way, it's a valid decision if Google decides not to implement the requested feature. But there's a difference between "We're not implementing a feature for power users" and "We're not implementing an accessibility feature for disabled users."
The whole point of ADA is that we should strive, where possible, to allow people with disabilities to live the same lives everyone else enjoys.
As a lefty, I've often felt frustrated, or even furious as the ignorance of UX for those of us that don't fit the norm.
The comments from the developers that responded to this clearly showed such ignorance, that it's a "power-user" feature etc. If I use my mouse left handed, as a left-handed person, is it a "power-user" feature to want the buttons the opposite way around?
You'll probably find that the less stubborn lefties of the world, such as myself, have actually developed into a form of ambidexterity. Not entirely ambidextrous (I can't write well with my right hand, for example), but something of the sort. I'm a lefty, there is no doubt, but I use a computer like any other right-handed person (apart from using tenkey-less keyboards, because a numpad is useless to me).
This is the option we have when the world around us is created for everyone _else_.
I once worked for a company that was commissioned by a local government body to add accessibility features to the company's own (local travel) app because it was unusable by the members of the community that required those accessibility features.
This is great, but, the task was given to me. What experience do I have with resolving accessibility problems? I'm just a developer. Was I given the resources to go out and survey those that required the accessibility features? Was I given contact with the local government that commissioned the improvements? Was I given a book on "Designing & Developing with Accessibility in Mind"?
No.
I completely understand where OP is coming from with this, and when the problem is with a company as large, ethereal and ignorant as Google is, it goes beyond frustration.
That's supported.
What isn't supported is mapping arbitrary buttons to arbitrary functions because that's a hard problem to solve generically: see Evoluent having to ship their own customization software for Windows and Mac instead of just using OS configuration screens.
A more appropriate example might have been scroll-bars, very few devices support moving them to the left. particularly when it's a touch device and I want to actually use my left-index finger, or a stylus (a la Nintendo DS, et al).
This is not a hard problem to solve generically, but it is rarely solved in my experience.
I agree with what you're saying, the problem I see is that OP has pointed out _why_ this feature is required (accessibility) but 5 years later it's still not solved.
This is frustrating as the person that _needs_ that feature.
If any one of those developers had _needed_ the feature, I bet it'd have been implemented in no time at all.
The people responsible aren't affected, and thus don't care. When your user-base is as large as Google's, a small feature like this might affect more people in that tiny minority that the entire customer base of some small companies, but at this scale they're so far removed, nobody cares.
Talking of features we want Google to add; when are they going to finally allow us to set the hostname on Android phones? I'm sure that one was opened half a decade or so ago (This one issue is now 9 years old: https://issuetracker.google.com/issues/36912590)
The ticket the blog author refers to was opened by someone @google.com. There are at least 5 different additional @google.com addresses chiming in in favor of such a feature.
Even when developers want something, they don't always get it on the schedule they desire.
Given the big Chromebook push into the education space, accessibility issues like this which impact the 5% of "edge cases" out there are actually really critical. There's no good excuse for skimping on accessibility. The fully-abled developers on the project--who likely don't work with anyone with disabilities, much less have they ever considered what it would be like to use their products with disabilities--have fully embraced the data-driven, A-B tested, "simplicity" (for most) at all costs approach that doubles down on human biases against disabled individuals, but just because they aren't actively choosing the predictable consequences doesn't mean they aren't responsible for the predictable consequences.
The OP isn't asking for some beautifully engineered UX with GUI that walks you through every possible disability modification. He's more than happy to go through a long procedure [1], as on Linux, to get that memory block to point to a different address. He just wants it to be exposed at all.
Others have claimed that this is some kind of full-featured thing. Well, as best I can tell, his Linux workaround just involves xinput and lsusb, both of which are available on Alpine Linux, the ultra-minimal distro.
[1] https://shkspr.mobi/blog/2018/05/using-the-evoluent-vmcr-c-s...
For arguments sake, if this was a physical issue that couldn’t be worked around in software, what would you do? Are there mice out there that themselves can be programmed to achieve the same end result?
So standard that Evoluent needs to ship its own customization tool for Windows and macOS?
The feature request is the ability to map arbitrary buttons (of which there can be many more than 3) to arbitrary actions.
You generalize from your one issue to "Google doesn't want unhealthy people using its products" (despite assertions somewhere else here that some aspects of accessibility are rather good and thereby help "unhealthy people [use the] products").
You're reacting rather offended to attempts to explain why your favorite bug didn't get the attention you think it deserves.
The most reliable way to get ignored is to throw a temper tantrum, so maybe calm down?
(as an aside: I find Chrome OS to be quite usable without mouse buttons when using keyboard short cuts, with the touchpad acting as scroll wheel. Could that be a suitable workaround for you? Also: left button is double-tap on the touch pad, which doesn't care which finger you use)
Your issue is that you can't configure your 3rd party mouse with nonstandard buttons to work in a custom way. Because of that, you're ranting about all the able-ist jerks at google who while putting in the effort to make things accessible for the blind and the deaf, don't seem to care about implementing your specific workaround for inflammation in your finger.
The world can't give you 100% of what you want 100% of the time. The important thing is that the people who really need help get it.
20% of the population is left handed and can't use Chromebook comfortably because of this bug.
Everything else the OS can't really expect to work. There's a reason why vendors of such advanced input devices provide their own config tools for Windows and macOS: both systems don't even try to support that clusterfuck out of the box.
People are saying that OP's blog post is the wrong way to drive change, and they're probably right, but nothing else -- short of going through the courts -- works.
No it isn't. The ADA does not apply to products, including software. Some websites are within the purview of Title III.
If I make a toaster, I am under no legal obligation to ensure that my toaster is accessible. I have a moral obligation (and potentially a commercial imperative) to make reasonable efforts to ensure that it is usable by the widest possible range of consumers, but it is simply not practical to ensure that my toaster is usable by every possible person with every possible permutation of needs.
http://www.storm-interface.com/media/catalog/product/cache/1...
Why are you assuming I'm talking about the US?
a) Get a mouse with internal memory, like the Logitech G700. Program on Windows, then use with the Chromebook. Not sure if there's a "vertical mouse" equivalent.
b) Crouton (or other Linux on CB solution) + xinput
You shouldn't have to do either, but perhaps it's better than nothing.
Making a physical device accessible to everyone gets into zero-sum design decisions, whereas Google's going to have a hard time arguing that a feature X11 has had for decades is something beyond its resources to implement.
I don't know, Mozilla had an easy time justifying how they broke the key remapping API with no replacement [1], even though Super Metroid (1992), on the SNES, allowed you to do that. SMH.
[1] Extensions can remap keys ... after a tab's page has loaded. Which means that if you have move-tab-left/right remapped, you can't sail through the tabs because they'll randomly stop to wait for the page to reload.