Better inclusivity #87570
Comments
|
I generally agree with what you've written except for the part about node-gyp. If the bug is upstream, then the onus is on gyp to support it, whether it be tomorrow or next year. That's where the concerned people (aka yourself) should be focusing... VSCode has over 4000+ open issues in this repo, 3900 too many in my opinion. Most are just sitting there without anyone taking charge and solving them. So I wouldn't read too much into the subtleties of how individual issues are managed. It could be a Microsoft employee glossing over something between his coffee and toilet break. |
That actually would make it worse, because that would emphasize that accessibility concerns aren't worth more time than you'd spend scrolling a social media feed. |
|
I think it would emphasize more the complexity of a large project like this, and how accessibility is just one concern (if the project even bothers to address it). Everyone's jostling for what's important to them, and the VSCode team has to manage this somehow. Best thing to do is make a pull request that they can't ignore... why wouldn't they happily accept it? |
|
I'm not trying to be rude here, I just don't get how when someone isn't able to use the software well because of impairments, they would be able to reasonably navigate such a large code base to fix the issue. We're not talking about the general feature request here, because then I would absolutely agree with you. For many of these, it is limiting factors that keeps people with certain disabilities from being able to reasonably use the software. |
|
While thinking about what I said, I think that in my effort to finish up quickly, I wasn't clear about what I beleive to be the key issue. So I should add that. For one of the examples I cited, I also gave a possible solution that shouldn't impact the currently intended workflow. This solution would not change anything about what happens when a notification is received, and would only introduce a key chord to switch to that context. While I certainly agree that Open Source empowers people to fix problems they may face, that's not the issue here. Many of these issues are closed with what amounts to "working as intended". Between no discussion, immediately closing them, and the responses given, I feel that if I were to create a PR with the possible solution that it is unlikely to be merged as it's already "working as intended". Aside from the aforementioned reasons for this, I'm also basis thing on a very common workflow pattern used in OSS: Filing an issue for the bug/feature, discussing its implementation, opening a PR addressing that issue, and then working on the implementation, eventually reviewing and refining until the merge. I hope this clarifies where I am coming from. |
|
Let me try to respond to the points you made. It seems there are two about accessibility
and one about approachability
About 1: An exploration of how to enable universal icon theming is on the January plan. To my knowledge the first time icon configurability was called out as an accessibility issue was November 12, 2019. Up to that point the discussions were around general UX and look. About 2: This is the list of all issues we have labeled with About 3: You outlined the impact of our dependency on |
|
I guess I lack the necessary skills to get my point across. Hopefully someone without the problems I face can convey the intended message better. |
|
@Entomy your issues were concisely addressed, point by point (at least that’s how I read it). If you think they are all missing the mark, why not elaborate? Only further discussion will make things clearer. |
Lord, C., Risi, S., Lambrecht, L. et al. The Autism Diagnostic Observation Schedule—Generic: A Standard Measure of Social and Communication Deficits Associated with the Spectrum of Autism. J Autism Dev Disord 30, 205–223 (2000) doi:10.1023/A:1005592401947 Mundy, P. Sigman, M. Ungerer, J. et al. Defining the social deficits of autism: the contribution of non-verbal communication measures. J Child Psychol Psychiatry 657-69 (1986). doi: 10.1111/j.1469-7610.1986.tb00190.x I understand my limitations quite well, certainly better than others understand my limitations. I shouldn't have to resort to citations to explain and prove those limitations. |
|
@kieferrm I'm reopening this as I've found things that I believe better express the concerns and limitations I was trying to express. While not a website, I believe the accessibility principals here still apply WCAG 2.1. Of most interest is Principal 2. 2.1.1 specifically covers the concern we've gone into most detail about. G202 covers the guidelines for implementing this and contains the relevant passage:
As far as accessibility guidelines go, WCAG 2.1 encourages everything be accessible from the keyboard, with no such encouragement about the mouse (because the mouse, or devices that emulate the mouse, are immensely harder to use for some people). You said:
Assuming I did my homework right, your professional career started with research. If I got that right, then you know this isn't research; this isn't even considered good survey practices. It's still good to do, as it does gather much needed information. But I hope we can both agree that it's better if we "stand on the shoulders of giants" and listen to people who's passion and careers are about accessibility concerns, not programming. Morris, M. R. AI and Accessibility: A Discussion of Ethical Considerations. Microsoft Research.I'm including this one just because of the passage at the beginning.
As an aside, that's some very interesting research and I look forward to what comes from that! Roulstone, A. Disability and technology: An interdisciplinary and international approach. Psychology.doi: 10.1332/239788218x15224822470889 That roughly covers, in part, how often individuals without any experience of disability, which I took to mean either directly effected by, or intimately familiar with someone effected by, a disability. While I hope that's not the problem being faced here, the impression I have is exactly this. ROBINSON, JERRY, "A PHENOMENOLOGICAL LOOK AT THE LIFE HACKING-ENABLED PRACTICES OF INDIVIDUALS WITH MOBILITY AND DEXTERITY IMPAIRMENTS" (2018). Dissertations - ALL. 872.This is a great read, and one of the few mentioned here which can be freely accessed. I would encourage a cursory review from the entire team, although I understand as a dissertation it is very long. It does, what I would consider, the best job I've ever seen covering this issue in its entirety. I'm not going to cite from this because it's something I read shortly after it was published, and I'm not going to reread the entire thing just for trying to make an argument that I'm not particularly hopeful about resolving. Universal Access in Human-Computer Interaction. Methods, Technologies, and UsersA book, not research, but considering it's coming from Springer I'm assuming you know the kind of book it is. It has some very useful information about designing for accessibility, and generally agrees with the WCAG 2.1 about keyboard accessibility. ATKINSON, M.T., MACHIN, C.H.C. and SLOAN, D., 2008. Making accessibility accessible. IN: Accessible Design in the Digital World (ADDW), 24th September, University of York, York, UKThis article primarily covers problems with industry adoption, but should be insightful as well.
I believe this also pretty well describes my concerns, and definitely fits with what I'm seeing. |
|
At this point I've spent more than $100 gathering others words, just trying to prove my point, because I lack the actual skills I need. This is just further discouraging me and heightening my concerns. Is it just this project? Is it all of Microsoft?
There's a problem here. One that's painfully apparent to me given my own experiences. Allow me to explain. Despite being diagnosed when I was 15, I was never made aware of any kind of therapies or assistive technologies or accommodations that could have benefited me. I'm 29 now, and playing catch up with many skills that could have been developed. I wasn't aware of vocational rehabilitation services until a year ago. I wasn't even aware of organizations like Autism Speaks until just a few months ago. When you look for individuals using assistive technologies you're only finding a subset of individuals with impairments. Even worse, you're finding the subset who's managed to achieve at least some level of accommodation. There's another subset of people who likely aren't even aware that there's potentially easier ways they could be doing things. While I don't have any research to back this up, and I'm not paying to read any more articles at this point, I think it's pretty obvious that this subset of people would be the most easily discouraged. I can, at least in a limited capacity, confirm this from personal experiences. For roughly five years I worked in the medical field, primarily doing long term or post-op care for people with temporary or permanent physical impairments. I've worked with individuals with anything from cerebral palsy to muscular distrophy to paradactyly to myasthenia gravis, and more. I would regularly see physicians and physical therapists get frustrated over lack of any kind of fitness attempts, and it was regularly written off as they "were depressed" or "didn't care". And yet I could get about 4/5 of them actually doing stuff, even without prompts. I think it's because while I don't understand the physical impairment part of it, I do understand the impairment side in general. Not a single one of them were even aware of assistive devices or other accommodations that they could use. Based on a few of the things you said, it seems like better transparency and a slight change in workflow might help a lot. I would encourage leaving accessibility issues filed by your internal team open, until a solution can be found, or it can be shown that a notable amount of the effected community already has an out-of-software solution. Furthermore, collect these issues. Maybe as a Project? I've seen these as useful for organizing general issue classes in other projects. Obviously there's many different possible solutions, not just what I've suggested. I haven't well thought out the solution and others might have better ideas. |
Entomy
changed the title
|
Oh isn't that a clever way of keeping accessibility concerns from being dealt with. Now it'll go a certain period of time and be closed because of something not even applicable in this instance. And then when people look, it won't be your fault for completely ignoring this and pretending like there's nothing to talk about, it'll be my fault for not providing information that doesn't apply in this context. I'm literally just trying to point out, both from personal experiences, and my own experiences working with the disabled, professionally, for five years, that there are some flaws in your approach, and some minor changes to that would see huge improvements. Why you wouldn't want to hear someones professional experience and suggestions in a matter considered important to this project is beyond me. |
|
oh it still exists |
|
oh it still exists... |
|
I think the solution to what you're saying is for the page where you download VSCode to have a link in a noticeable place to the accessibility docs. |
|
It's not strictly that there are UI elements that are only accessible by mouse, although I have found a few cases of that. It's that there are UI elements that demand attention (like occluding the editor space), and require several dozen keypresses to actually get there. So, mouse isn't required in the strict sense, but it's still obviously way easier to use a mouse. Yes, essentially what you are proposing is the solution. |
|
There isn't any information to add unless Kai has some questions. Dude's just ignoring it 🤷♂️. |
|
It still exists. I now have reason to beleive this is fundamentally a problem of management, specifically the PM's. But until it's addressed, I can't, and won't close it. |
|
Please could someone stop the bot? It is polluting this thread. Thank you. |
|
Aye, and it's just a constant reminder that they're hoping attrition will get this closed. 😕 |
and others
Because of the recent controversy, I had put forward this issue in an effort to understand whether or not I could reasonably contribute to this project. It was explained that my worries were not well founded. As explained in that issue, I was looking for a Microsoft project I could contribute to.
I do not like conflict for various reasons that stem from my upbringing, and do my best to find a compromise and to diffuse a situation. Requests like 1, 2, 3, 4, and others, demonstrate many reasons for wanting something that I've wanted myself, and am more than willing to implement: the UI icons should be subject to extensibility, just like the rest of VS Code. Not only would this solution accomodate both the groups who want no/different holiday themed icons and the groups who want holiday themed icons, but it would also accomodate those who certain theming isn't applicable at the same time of the year, which could have avoided the very mistaken attempt at using a snowflake instead, despite literally half of the four-seasonal regions being in summer right now, and the equatorial region not experiencing winter. But it happens to go further, as an accessibility thing. As mentioned in my initial issue, I am autistic, which has a very high comorbidity with sensory integration disorders, of which I also have. Some of the icon designs give me trouble. Here's where I beleive your approach is wrong, and further reason why extensibility is the appropriate way to handle this. SID's work in drastically different ways, and what gives me trouble can easily be totally acceptable or even pleasing to another individual with an SID. There is absolutely no universally accommodating approach for SID problems. While looking into this, I had discovered that it's not just SID's that present problems with the default UI icons, as there's at least one individual with nearsightedness that struggles due to design concept of the icons, not anything about a particular icon. However as I have seen from several twitter polls from this project, many people do like the existing icons. They still deserve to have those icons. For all of these reasons, I am sure that extensibility is the appropriate way to resolve all of these issues, and as I had stated, was more than willing to implement this.
So, I had gone through the process of cloning the VS Code repo, and installing/configuring all the required tooling. The process was difficult but I got it working.
There was one particularly difficult part of the build system that I reserved for a different issue. My understanding is that VS Code relies on node-gyp, which is more or less a repackaging of gyp, a project generator similar to cmake. gyp is unable to to handle non-ASCII user profile paths on Windows, which means node-gyp is unable to handle non-ASCII user profile paths on Windows, which means VS Code's build tools are unable to handle non-ASCII user profile paths on Windows. Aside from the obvious techncial deficiencies and very out-of-date nature of this software, it poses a problem I beleived to be a barrier of entry to contributions of this project for individuals who's primary language is not covered by the ASCII character set, making their username unlikely to be covered by the ASCII character set. Having to create a new user account and migrate necessary things over just to contribute to a project is an unreasonable burden on most of the worlds people, especially with how much globally aware software exists now. Per the Microsoft Open Source Code of Conduct:
and
Yet for many people around the world, contributing it more difficult than a very select group.
Now to be clear, I fully agree this is an issue with upstream software. Gyp is the problem. However, I do not understand why this issue was closed. To me, it comes off as "it's not an issue" because "it's someone elses problem". VS Code is still effected by this, even if it's someone elses responsibility to fix it.
My main area of programming has to do with text, and I've done an entire ASCII -> UNICODE migration in a language runtime before, so surely I can update gyp to be more globally aware as well. So I go clone gyp and start looking through it. There are some older complaints about the aforementioned, with some even included patches that never made it to the right people. However gyp has changed so much over the years that the patches would not apply anymore. So while I'm poking throughout the code, I take some breaks to also poke through VS Code issues others have filed, so I can keep in mind other areas I might be able to contribute to. This is where any and all confidence about inclusivity in this project starts to die.
I want to explain at this point, that my head and eyes are starting to hurt quite badly because github's text editor is too cramped and it bothers me. So I'm going to make this much shorter than the full extent of what I have found. I will only be citing a few of the over two dozen alarming issues I have come across. The change in my perceptions was not just a "oh look at this odd example I found".
There are numerous examples 1, 2, 3, and more, of accessibility complaints being immediately dismissed, because the existing design works appropriately for fully-abled individuals. One of the dismissive comments is, I beleive, extremely unselfware. Dismissing navigational difficulties involving notifications on the basis of "extensions are using them wrong" only holds logically if this project and the official Microsoft extensions are holding true to these principles. This is where the lack of selfawareness comes in. Simply navigate to source file for a language in which there is no extension installed, but is available in the marketplace. What comes up? A notification about the extension. A notification that a disabled person, depending on their input methods, will either have great difficulty navigating to, or be unable to navigate to. "But this is just a notice" right? No, it's a convenience, which is why this particular example is so interesting. Because no keyboard navigation methods exist for switching over to it, cursor movement is required, which is substantially more difficult for certain disabilities. This means that despite the convenience all fully-abled people are afforded, and some disabled people, that other disabled peoples will instead have to navigate to the extensions tab, type or speak (and hope its recognized) the extension name, and then still navigate over to install. I completely agree
tabshould not be used for this purpose. However, a keybinding for switching to a notifications context would be hugely beneficial for these people. And that's where we get into the other issue. How these were handled is unacceptable. Rather than explain why, I think it would be more constructive and better representative to explain roughly how I think things should have been handled. First, explain why things are in their current state. Second, explain the intended workflow. Third, ask the OP if the intended workflow is suitable, and if not, to elaborate on why it's not and what a possible solution might be. This is encouraged by the Microsoft Open Source Code of Conduct:And yet, this was not done on a substantial number of issues.
And unfortunantly, I can't even comment on the most serious issue, because I beleive it might cause myself to violate the CoC. So that's unpleasant and I'm not sure how to go about resolving this one.
From what I have seen, I do not at all feel like this project is inclusive in the way it intends to be. Certain types of inclusivity issues are given more priority than others, with disability/accessibility issues seeming to be the most dismissed. I do not feel comfortable contributing to this project. I hope these issues can be resolved.
The text was updated successfully, but these errors were encountered: