• 9 Posts
  • 16 Comments
Joined 1 year ago
cake
Cake day: August 10th, 2023

help-circle

  • Linux won’t be viable for blind people unless major distros have full time accessibility folks, and refuse to accept inaccessible packages and patches.

    Sure, but you need to read what I quoted. I purely addressed the flawed claim that better code comes from those paid to write it. The opposite is true. It’s unclear to what extent that bias has influenced @noahcarver@rblind.com’s thesis. Though I have no notable issues with anything else @noahcarver@rblind.com wrote (much of which is beyond my expertise w.r.t accessibility).

    And to be clear, “better code” strictly refers to quality, not accessibility. Accessibility is a design factor.

    But that code you write at home is probably not accessible.

    That’s right. But then neither is the commercial code I worked on. That would be outside of my domain. I do backends for the most part. The rare UI work I did was for a tiny user base of internal developers within the org and accessibility was not part of the requirements. I worked on a UI for external users briefly but again no requirements for accessibility (which would be very unlikely for that particular product).

    In any case, this sidetrack is irrelevant to what you replied to. It’s important to correct bogus claims that being paid to write code is conducive to quality. Some right-wingers I know never miss the opportunity to use the phrase “good enough for government work” because they want to push the mentality that capitalism promotes superior quality. It’s a widespread misconception that needs correction whenever it manifests.

    Paying someone to write accessible code should theoretically work on both free software and non-free software. AFAICT the reason non-free software would accommodate blind users is that the market share is large enough to justify the profit-driven bottom line and those users are forced to pay for it (as all users are). In the FOSS domain, payments (“bounties”) are optional. Has this been tried? If not, then you’re relying on blind FOSS developers to suit their own needs in a way that benefits all blind users.


  • and that someone who is paid to write accessible software is generally going to produce and maintain better code.

    In my day job I’m paid to write code. Then I go home write code I was not paid for. My best work is done without pay.

    Commercial software development

    When I have to satisfy an employer, they don’t want quality code. They want fast code. They want band-aid fixes. The corporate structure is very short-sighted. I was once back-roomed by a manager and lectured for “gold plating”. That means I was producing code that was higher quality than what management perceives as the economic sweet spot. I was also caught once fixing bugs as I spotted them when I happened to have a piece of code checked out in Clearcase. I was told I was “cheating the company out of profits” because they prefer if the bug goes through a documentation procedure so the customer can ultimately be made to pay separately for the bug fix. Nevermind the fact that my time was already compensated by the customer anyway - but they can get more money if there’s a bigger paper trail involving more staff. So when you say you get what you pay for, that’s what you pay for – busy work (aka working hard not smart). They also want “consistent quality”. So if one module is higher quality than another, there is pressure to lower the quality of the better module because improving the style or design pattern of the lower quality piece is “gold plating”. When I make full use of the language constructs (as intended by the language designers), I am often forced by an employer to use more basic constructs. Employers are worried that junior engineers or early senior engineers who might have to maintain my code will encounter language constructs that are less common and it will slow them down to have to look up the syntax they encounter. Employers under-estimate the value of developers learning on the job. So I am often forced avoid using the more advanced constructs to accommodate some subset of perceived lowest common denominator. E.g. if I were to use an array in bash, an employer might object because some bash maintainers may not be familiar with an array.

    Non-commercial software development

    Free software developers have zero schedule pressure. They are not forced to haphazardly rush some sloppy work into an integration in order to meet some deadline that was promised to a customer by a manager who was pressured to give an overly optimistic timeline. #FOSS devs are free to gold plate all they want. And because it’s a labor of love and not labor for a paycheck, FOSS devs naturally take more pride in their work. I’m often not proud of the commercial software I was forced to write by a corporation fixated on the bottom line. When I’m consistently pressured to write poor quality code for a profit-driven project, I hit a breaking point and leave the company. I’ve left 3 employers for this reason.

    Commercial software from a user PoV

    Whenever I encounter a bug in commercial software, there is almost never a publicly accessible bug tracker and it’s rare that the vendor has the slightest interest in passing along my bug report to the devs. The devs are unreachable by design (cost). I’m just one user so my UX is unimportant. Obviously when I cannot even communicate a bug to a commercial vendor, I am wholly at the mercy of their testers eventually rediscovering the bug I found, which is unlikely when there are complex circumstances.

    Non-commercial software from a user PoV

    Almost every FOSS app has a bug tracker, forum, or IRC channel where bugs can be reported and treated. I once wrote a feature request whereby the unpaid FOSS developer implemented my feature request and sent me a patch the same day I reported it. It was the best service I ever encountered and certainly impossible in the COTS software world for anyone who is not a multi-millionaire.













  • Orca is not installed by default on Debian. But I would be interested in seeing what the built-in tools do. In Firefox I hit F12 » Elements and saw an “accessibility” tab. From there I expanded a quite long tree of nested elements and got down to the hyperlinked image. Then I looked at the console frame with the link highlighted. There were over 30 messages with 6 errors. It’s very noisy. None of the errors or warnings indicate that the object would not be readable by a screen reader. It’s stuff like net::ERR_BLOCKED_BY_CLIENT and JSON parsing syntax errors.

    EDIT: this error looks interesting:

    city:60 GET https://cdn.equalweb.com/core/4.5.6/accessibility.js net::ERR_BLOCKED_BY_CLIENT

    If I understand correctly, Firefox is trying to run accessibility.js but because cdn.equalweb.com is a #Cloudflare site, I am blocked (Cloudflare is Tor-hostile). There’s a bit of irony here that a domain name “equalweb” leads to a discriminatory web server. I’m guessing this blocks Tor-using Firefox users from checking the accessibility of a webpage using FF’s built-in features.

    EDIT 2: it turns out accessibility.js is loaded by the site, not FF. So I’m not sure how to use the built-in functionality to answer the question.



  • I think this is a regression. IIRC, there was a time when a removal only removed it from the timeline. You could still reach it via the modlog. IIRC. But those days are gone. It’s a shame because it’s important for the community to be able to evaluate the mod’s decision making.

    I’ve even seen cases where an over-zealous mod gets embarrassed by the mod log and purges the mod log itself to remove traces of the censorship itself. I suppose that’s only possible if the mod is also an admin.