So just because this specific person has an issue that doesn't allow them to use a Chromebook they should make a blanket statement that they are inaccessible? I'm totally blind and have had a Chromebook for several years. I got it as a gift because I was interested in its accessibility. I've seen Google make large strides in accessibility in the couple years I've owned it. It went from barely usable to something I am comfortable using as my only computer if I don't need to do any programming. Just because something may not be fully accessible to someone does not mean we should ignore all the work companies have done to move accessibility from nonexistent to decent.
I'm extremely glad that Chromebooks are accessible to you. But they are not accessible to me.
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.
> 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.
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.)
The basis of solidarity is "an injury to one of us is an injury to all of us."
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.
You know those tactile paving bumps at pedestrian crossings? They're used by blind people as a navigation marker. Wheelchair users hate tactile paving, because it's extremely uncomfortable to roll over and can cause stability problems.
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.
That sounds incredibly utopic. Anyone at any time can have a completely new disability which renders any product unusable to them. It is not reasonable to expect companies to have a moral obligation to accommodate every single human being on the planet. Nor would it be economically viable for many products.
(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)
To a certain extent, accessibility as a value, means doing some things despite their unfavorable economics. The proverbial example is wheelchair access.
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.
Clearly several people working at Google have already noticed because they replied to the report on the issue tracker about it, and they all said that implementing this would be a good idea.
I use Windows 10 machines and make heavy use of WSL. I use Eclipse as my IDE when doing Java work. I use Jaws for Windows as my primary screen reading software and NVDA occasionally for things it handles better then Jaws. I used to own a Mac but booted it into Windows most of the time once WSL became a thing. In my limited experience the Mac is OK for general computing from an accessibility perspective but does not offer the screen reader customizability and efficiency that Windows does.
https://www.freedomscientific.com/Products/Blindness/JAWShttps://www.nvaccess.org/
The absence of a desired feature is not a bug. The author's situation is clearly very frustrating, but Chrome OS is intentionally minimalistic. Just one feature isn't going to result in bloat, but there are thousands of users who want just one feature. If he had bought an iPad Pro instead of a Chromebook, he would have been disappointed to learn that iOS doesn't support mice at all. A version of Chrome OS that supports every possible use-case and customisation is just linux. We already have linux.
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.
> 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.
... 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.
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.
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.
While it would be nice if every change that could help a disabled person could be considered a problem with the product until implemented, that's simply not possible. It's not possible for small teams, who don't have time to implement every feature, and it's not possible for large teams, who have to deal with problems like feature bloat in what is a very simple product from a UI point of view.
Many people are forced to use it, especially in educational settings. In fact, this kind of accomodation is the law, at least in the United States. A long series of ADA lawsuits have forced platforms like Scribd and Kindle to make their platforms accessible. Unfortunately bringing these lawsuits is expensive and difficult and the battles have to be picked. Google doesn't have a great culture of accessibility, and yet more of their products are becoming required for educational and job settings.
The developer comments are so... modern? I don't know. Normally I'd call it "Open Source Dev" mentality, but sadly it has infected non-OSS devs too who don't even have the excuse of working for free.
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?
>Normally I'd call it "Open Source Dev" mentality,
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 thing is, the encounters with Open Source people you remember and that color your conception of the community are the ones where the dev ignores issues for years, blames the user, and WONTFIXes legitimate problems. It's made all the worse by evangelists who try to tell everyone how great open source is and how everyone should only use open source software, only to turn around and tell people to fix or implement something themselves when legitimate issues are raised.
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.
Obviously, no FOSS developer can deal with all user's issues, especially when they don't pay. They have to drastically limit scope. That means saying "no" to some users and their issues. FOSS developers nevertheless should be able to evangelize their software to users in general. Nobody expects a "thank you" when you don't actually use the software.
In a reasonable world what would happen is the developer would say "hey, try my software", and the user would say "sorry, I don't like it/can't use it because of X", and the developer would either say "you're right, I should fix that" or "ok, fair enough". In my experience, this is not what happens. What happens is they tell you that your use case is invalid, your workflow is wrong, you're too stupid to get it, or a bunch of other lame excuses and then still think you should use their software or even fix it for them.
If you criticize somebody's work, they'll get defensive. That's a totally normal human reaction. Users rarely say things like "sorry I don't like it", it's more likely they file their pet peeve as a major grievance that supposedly affects untold numbers of other users, like the guy who wrote this blog post.
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.
Likely any grievance one user has is shared by many other users who are silent about it, because those others didn't even care enough about your software to bother posting an issue. Worse, you often see this same grievance aired time and time again over years and it is still dismissed out of hand.
>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.
> 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.
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?
> For all intents and purposes, if you fail to make a convincing argument for a use-case to a developer, it is invalid.
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.
I'm guessing the GP was referring to the sheer arrogance of many open source devs/projects where comments/requests/bug reports are often met with "works for me" or "if you don't like it don't use it" kind of responses.
The majority of OSS devs, like the majority of human beings, are basically decent and just trying to get through the day. However, some of the most prominent ones are famous for being a-holes (e.g. Linux Torvalds, Theo de Raadt, and especially Ulrich Drepper[1]). They aren't "giving their time and talents to the world for free." They're trading their code for the opportunity to verbally abuse people, and we should not ignore that.
I don't see an issue with Ulrich's behavior here. Calling somebody an idiot after being called "a terrorist" seems rather fair. Being a somebody, of course he is going to be the center of attention, not the dozens of nobodies annoying him into reacting like that.
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.
Because it's always a choice. You have a choice between implementing a new feature (that could earn you/your company money directly), or making an existing feature more accessible, which might make a very small number of people happy/enable them to use your product, and the profits from such an endeavour are probably smaller.
It should be practically 0 cost to implement these things, except that, as an industry, we've built up such a giant mountain of crap abstractions that it isn't anymore, and we apparently don't care because it won't line anyone's pockets. Forgive me if I care enough about personal computing to hold it to a higher standard.
This is particularly strong with the Chrome team and other parts of Google. In order to protect that $2M revenue/employee, they only build things for the generic mainstream or high paying advertisers. See also YouTube's video recommendations.
If you want a computer, get a computer. If you want a cheap Google ad-viewing portal, get a Chromebook.
This comment spreads misinformation IMO. My first laptop was a chromebook and it treated me well for years, albiet with chrubuntu.
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.
> That's when I discovered that accessibility is very much a second thought for all the young and healthy people Google employ.
> 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.
Come on, your second example is silly at best. You are seriously saying that the middle O in their Google logo has bad contrast, and therefore they don't care about accessibility?
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.
I work at Google and have colleagues with accessibility needs, so the idea that nobody there does is false.
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.
It's not rude. It looks like the truth. Google UI decisions show a huge bias toward specific setups and preferences. Just look at how Google Maps displays on a low-resolution desktop to see what I'm talking about. The new, bloated Gmail design is another example..."I have infinite RAM and bandwidth so this is great!" The average Google employee is 29 years old, and the average one working on a UI is way younger. They're also, generally, super fit rock climbers with 20/20 vision. If This demographic is describing you pretty well then it might be hard to see the bias.
Isn't this a problem for the device manufacturer to write a driver that supports ChromeOS? Or a hardware toggle for the buttons to switch them?
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.
While it could be a driver/hardware solution, I know that windows supports it, (I'm sure linux too), so it could be an OS solution, and my guess is that it wouldn't be too much work (tm) to add it.
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.
Accessibility isn't an edge case. For one thing, it's a legally mandated requirement.
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.
>For one thing, it's a legally mandated requirement.
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.
You are correct in this case, but I'd just like to point out that some specific objects/products do need to be accessible. For example, all new kiosks that you can use in airports for immigration or self-service check-in/bag-drop must now be accessible. You can recognise them from the headphone jack and ezaccess keypad:
The kiosk constitutes part of a public accommodation, which is covered by Title III. A light switch doesn't have to comply with the ADA; a light switch installed in a hotel or restaurant does.
Section 29 of the Equality Act 2010 applies to services (including websites) but not goods (including software). I am not aware of any case law in which Section 15, 19 or 20 has been applied to goods.
Nice to be called an "edge case". Really makes me feel valued as an individual.
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?
> There are thousands of unhealthy people who are being deliberately excluded from Google's cheap computing revolution.
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.
It amounts to the same thing. Google decision-makers are aware they are excluding a significant chunk of "edge cases" in order to hit their profit goals. They don't think of it in terms of "let's screw over people who need to remap mouse buttons because of physical disabilities!" but that's only because they are actively choosing _not_ to think about the impact of their hyper-"logical" efficiency decisions.
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.
You can read all of the comments by the devs who aren't even considering the accessibility option. Remapping mouse buttons come across to them as someone trying to map keyboard shortcuts to the mouse buttons for better productivity in whatever apps they use for work.
> Remapping mouse buttons come across to them as someone trying to map keyboard shortcuts to the mouse buttons for better productivity in whatever apps they use for work.
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.
It's probably more like, "let's lock ourselves into an early design decision that makes it hard to expose input remapping without realizing that's what we're doing because the architecture looked so much cleverer that way".
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.
"Ignorance". That's the word we're all looking for here.
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.
> is it a "power-user" feature to want the buttons the opposite way around?
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.
My example isn't the greatest, I agree, because it is, generally supported everywhere.
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)
> If any one of those developers had _needed_ the feature, I bet it'd have been implemented in no time at all.
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.
They did though. They admitted on the bug that ChromeOS is not for power users, meaning anyone who needs a different configuration from the default. They didn't accidentally forget,they made a conscious choice, repeatedly.
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.
> They admitted on the bug that ChromeOS is not for power users
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.
>Needing to click with your thumb instead of your finger isn't a power user feature, it's an accessibility feature
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
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)
No one deliberately excluded you from anything. You have a trackpad that can be clicked with any finger you want.
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.
Addressing the issue in software seems like the obvious choice - especially as it’s a standard ability in other operating systems.
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?
Why couldn't you use a Chromebook comfortably because you are left handed? I am left handed and I use a mouse just like any other right handed person. I don't know anyone who is left handed and uses the mouse with their left hand. So saying that 20% of the population can't use Chromebooks comfortably isn't right in my opinion. I'm sure for some people it is a problem, I'm not trying to say that it's not. I also think that it's pretty stupid that you can't reassign the mouse buttons and I really don't like their response to the problem.
Or is there a different reason why it should be uncomfortable?
The left and right button (plus scroll wheel these days) are standardized and pretty much guaranteed to work on arbitrary USB mice because otherwise users would revolt. Even reliable support for the middle button was a matter of luck for a long time, years ago (that was before scroll wheels were a thing).
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.
After looking at the USB HID protocol for mice, I see what you mean. I was making the assumption that the button was detected by the OS and just not mappable by the user, but the protocol doesn't specify past the first 3 buttons so that isn't necessarily true.
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.
The sentiment expressed in many comments here are why it's only a matter of time before regulators are going to come down hard on the software industry with some ADA-esque law, and they'll probably be right to do so.
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.
>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.
If you put your Chromebook in Developer Mode, you should be able to access a root Linux shell and remap buttons there. However, I don’t think Chrome OS uses Xorg at all so your xinput solution won’t work to remap mouse buttons. The only solution that’s effectively guaranteed to work is to install Crouton and run a Linux distro of your choice on it. You would still have to deal with the annoying boot sequence and slightly less security.
So disappointed with all the comments defending Chrome OS because it aims for a minimalist design and doesn't add feature bloat. You can't really count accessibility and other features as the same thing.
Please don't respond to egregious comments by replying (a.k.a. please don't feed the trolls). Instead, flag the comment by clicking on its timestamp to go to its page, then click 'flag' at the top. (There's a small karma threshold before flag links appear.)
