12 ms·

Blind programmer here. Just a glimpse of my life. Blind people have to live in an environment where X% of web sites and programs are not accessible, where X var

• drewmol 7y ago
  I'm not blind but I'm laughing from reading your annecdote because: I'm a developer with typical accessability requirements who has a similar experience ordering pizza online and winds up calling ;-)
  • downtide 7y ago
    Easy to read/follow menu, and a phone call isn't that hard, with front door payment. Online shopping experiences vary widely. I love it when the interface isn't even noticed/gets out of your way.
• frittig 7y ago
  Thank you for your insight. One thing that I've wondered for a while is, what do you do about captchas? The whole point of them is to prevent access to the webpage unless a person sees the graphic. Can you sue Google under ada?
  • mehrdadn 7y ago
    I think they have audio?
  • mltony 7y ago
    Google's recaptcha is actually somehow really good - you just click on the checkbox and somehow it magically understands that you're a human, even when using a screenreader. Other websites have audio captcha. In the worst case, you can install a captcha-solving browser extension - they are typically 90% accurate.
    • toomuchtodo 7y ago
      Newer recaptcha uses your google account as a heuristic if you’re logged in.
      • michaelmrose 7y ago
        A disabled person should not need to opt into a google account to be able to browse the web
        • chopin 7y ago
          Not only a disabled person...
    • miki123211 7y ago
      > Google's recaptcha is actually somehow really good - you just click on the checkbox and somehow it magically understands that you're a human, Unless it doesn't. Yes, it gives you an audio captcha. No, it's not a good solution, as it's in english only, and a pretty good command of the language is required to solve it, especially now. If you use TOR for some reason (nosy admin in my case). They always ask you to solve the challenge, but when you click audio, you get a spoken prompt saying "this computer is sending too many automated requests, so audio captchas have been blocked". I don't know who you'd need to sue, though. Either Google for not providing you the audio version, Cloudflare from preventing you access (and outsourcing the verification to Google), or the website itself for getting Cloudflare protection.
• clamprecht 7y ago
  Is there some kind of "Yelp for websites for blind people"? In other words, a web site for blind people that lets you know whether a given site works with your screen reader? It seems like it could be a big time saver.
  • throwaway_bad 7y ago
    It there is one, I hope they made it styled with black on black text and/or with a braille font!
    • yoloClin 7y ago
      My guess is that your comment is satire, but you should be aware that 'accessible' doesn't just mean 'accessible to blind people' - among other issues, some people have reduced motor function, others can't see contrast as well as the typical human eye. WCAG is, from what I can tell, a reasonably good starting point and even attempting to do _some_ things and being generally aware is better than not doing anything at all. Give the guidelines a read, https://www.w3.org/WAI/standards-guidelines/wcag/ https://www.w3.org/WAI/standards-guidelines/wcag/
  • mltony 7y ago
    None that I'm aware of. The problem is checking whether a web site is accessible is a manual operation and therefore time-consuming. And it often happens that companies break accessibility, and then they fix it, and then they break it again...
    • flattone 7y ago
      Interesting. Accessibility sounds like an important indexing signal for search engines. At internet scale companies this seems pitch-worthy to discuss building some training data annotated and building out some automated indexing engine for accessible only filter for results.
      • propelol 7y ago
• Sukotto 7y ago
  In your opinion, what major sites are doing it right?
  • mltony 7y ago
    Websites from big IT companies tend to be good: Google, GMail, Youtube, Facebook, Amazon, Bing.
• ncallaway 7y ago
  I'd like to make sure I'm testing more of the website that I work on to make sure they're as accessible as possible. I want to do more than just run sites through validators. Is JAWS still a good accessibility program to test with? Are there other major accessibility programs I should be testing with?
  • markholmes 7y ago
    I’m not the parent comment, but VoiceOver and NVDA are great text-to-speech screen readers.
  • mltony 7y ago
    The big three are Jaws and NVDA for Windows and VoiceOver for Mac. You probably don't need to test with all three every time since they are similar in terms of what kind of content they can access on the pages. But each of them has its own quirks, there are web-pages that only one of them can read.
    • ncallaway 7y ago
      That's great. I can push to rotate between those three on deployments. I've typically only tested with one, so it'd be good to ensure there's nothing weird with others. Thanks!
  • limograf 7y ago
    There are so many great tools out there now. Lighthouse in Chrome Devtools has an Access audit built in which will give you a few hints. There's also a very useful auditor that just came out from Paciello Group called the Arc toolkit: https://www.paciellogroup.com/toolkit/ https://www.paciellogroup.com/toolkit/. Chromevox and Voiceover can be turned on to get quick screenreader-ish feedback. No Coffee: https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbnhckmgdhmgdckeigabjfbddl https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbn... is quite useful to get a non-scientific empathy hit for graphic decisions and how that interacts with common sight problems (98% of people by age 51 have presbyopia) and Sim Daltonism: https://michelf.ca/projects/sim-daltonism/ https://michelf.ca/projects/sim-daltonism/ will give you a more accurate representation of all the most common colour blindnesses (1 in 12 men). I also urge everyone to turn ON tabbing on their Mac (System Preferences > Keyboard > Shortcuts tab > All Controls) and tab into their sites (unplug your mouse). I also often do a run through with Vimium: https://vimium.github.io/ https://vimium.github.io/ which gives me some aspects of a voice interaction type system. These tools will get you some of the way there, though there are established ways to build components which will solve 90% of all known access problems. The main solution is simply to write native HTML. A major issue is how hard it is to style native form elements (like datalist) -- it means developers can't get it past design/clients.
• eloff 7y ago
  Pardon my curiosity, did you type this on a keyboard by touch typing? If so how do you recognize and correct typos? Or did you use speech recognition? Same question about handling errors. I'd like to make sites I build more accessible, but I must admit I'm only familiar with the bare minimal guidelines I've read in a couple articles. I don't even know if they're correct or up to date. Nobody I've worked for has ever made this a priority, so I'm quite ignorant on the subject.
  • jcranmer 7y ago
    > Pardon my curiosity, did you type this on a keyboard by touch typing? If so how do you recognize and correct typos? I'm merely a sighted user here, but I can personally attest that when you've mastered touch-typing, you can tell when you make a mistake and correct it without needing to look at the screen. It is a bit of an eerie feeling the first time you do it. Full disclosure: I touch-typed this reply, and I made five mistakes when doing so, and fixed all of them without looking at the screen.
    • personlurking 7y ago
      I've touch-typed for 20 years and sometimes a random friend (whose job isn't related to computers) catches me doing it and is either amazed or thinks I'm showing off. To me, I'm just typing. Like other commenters, I also self-correct while doing it.
    • eloff 7y ago
      I never learned touch typing, so I was unaware of that. I pick type with both hands without looking at the keyboard, but I have to look at what I'm typing on the screen to know when I've made a typo.
  • mltony 7y ago
    Yes, touch-typing. I feel when my fingers hit two keys at the same time - that's the time to go back and check the previous word for spelling mistakes. And I use screenreader to read things for me.
  • DoreenMichele 7y ago
• rgoldste 7y ago
  Curious, not trying to be a jerk. For something like ordering pizza (or even plane tickets), how much worse is calling to make the order as opposed to ordering online?
  • thomasedwards 7y ago
    Obviously you should just be allowed to use the same services as everyone else. The web is accessible by design, so all sites that are not accessible are broken. The people that made them broke them. But, just for the sake of your curiosity, American Airlines charge $35 per ticket[1] when you call them to book. [1] https://www.aa.com/i18n/customer-service/support/optional-service-fees.jsp#ticketing https://www.aa.com/i18n/customer-service/support/optional-se...
    • differentView 7y ago
      There's no way they don't wave that fee for blind customers.
      • pseudalopex 7y ago
        Domino's wouldn't give Robles the online price according to other articles.
        • chrisco255 7y ago
          Did they really go through an expensive legal process defending themselves in court rather than discount a large pizza by 10%?
          • berbec 7y ago
            Stupid franchisee. I kept a coupon active for years after the promo ended for one guy. He liked his $11.99 Veggie lovers. The coupon was hidden, but if you manually typed the code, it worked. I called him personally after he complained to corporate about the promo ending. I walked him through how to get the deal and he ordered weekly until I sold the store. The new owners deactivated all old promos. He had my cell phone number, so I got to find out, after I sold the store, thst he now orders Papa John's. Source: former multi-store, multi-Rolex winning Domino's franchisee.
• elliekelly 7y ago
  I don't know if this would even be possible but, since you're a programmer and all, it would be cool if you built a small webapp/task-based game for people who aren't vision-impaired to try to navigate and experience the frustrations you experience every day. A gallery full of mystery photos, random buttons that needed to be clicked a weirdly specific way or don't work at all.
  • oliveremberton 7y ago
    We wrote a free screen reader simulator for this purpose (Chrome plugin): https://silktide.com/resources/toolbar https://silktide.com/resources/toolbar It’s not a substitute for real-world testing, but it should help you appreciate the basics without having to learn a full screen reader. We’re also working on some accessibility games right now (scores challenges for you to complete in a browser with a simulated disability), which sound a lot like what you’re suggesting.
    • carlmr 7y ago
      I was surprised to find myopia here. Is there a level of myopia that can't be corrected with glasses and thus is a disability?
      • oliveremberton 7y ago
        Pathological myopia can't be corrected with glasses. TBH we call it "myopia" in the plugin because it's short and what we think most users would understand. Many visual disabilities cause a similar blurring effect, such as cataracts.
    • SquareWheel 7y ago
      This is great. Until now I've been using ChromeVox, but found it quite difficult to use. Many esoteric keyboard shortcuts, some of which conflict with other browser functionality. Toolbar seems a lot easier to to use for sighted developers. Less of a learning curve. Oddly M doesn't seem to jump to the main content for me. I wonder if I've done something wrong. I'm going to play with it. Thanks for developing this!
• yoloClin 7y ago
  I'm sure a bunch of people have inundated you with other questions, but what other pain points do you have? How are Docx and PDF to deal with?
  • mltony 7y ago
    Microsoft Word is fully accessible. As for PDFs, as long as they are not scanned, most likely they are accessible. Sometimes forms in PDF files are not very accessible. And also every now and then I need to read a science paper in PDF format - somehow they still haven't figure out how to make accessible formulas in Latex-generated PDFs, so I'd have to use an OCR called InftyReader to OCR this PDF to get the formulas. In my experience the worst offenders are drivers for printers and scanners. Every time my printer runs out of ink on my computer it'll show me a dialog, that my screenreader doesn't recognize at all. So by the presence of empty window I'll have to deduce that it's running out of ink. Scanner driver is completely inaccessible, so I had to get a linux box just to use my scanner - at least all the command-line tools are accessible.
    • Hitton 7y ago
      As for PDF accessibility, it heavily depends on used language. In English it's usually ok, but I saw countless PDFs (some of them written in TeX) in other languages that render ok, but the text actually consists of letters followed by appropriate diacritical mark.
    • hopesthoughts 7y ago
      Or those image PDFs that you have to use OCR with and then you get to try and clean them up afterwards because they didn't come out as cleartext. Those are always fun!
• mrep 7y ago
  Ironically (I cannot seem to word this in my mind without sounding like an ass so please don't take offense), your comment is about 10 lines long on my 15 inch laptop making it somewhat difficult to read for us vision readers. A double new line every few sentences which causes a paragraph on hacker news makes it much easier.
  • TheSpiceIsLife 7y ago
    Mildly amusing. I definitely find this a little annoying too. If you make the browser window narrower the eye has a lot less trouble moving from the end of one line back to the start of the next. I like wide screens because they make it better for having two apps side by side, rather than one app full width .
    • maigret 7y ago
      Hacker News could easily set a max-width on the problematic items. Every designer (and so should every web developer) knows that the sweet spot for reading is around 60 characters and a column of text if readable between 40 and 60 characters. Check for example the free course from https://betterwebtype.com/ https://betterwebtype.com/
      • u801e 7y ago
        > Every designer (and so should every web developer) knows that the sweet spot for reading is around 60 characters and a column of text if readable between 40 and 60 characters. That is interesting. For source code, I've always preferred maintaining a maximum line length of 80 characters. But there are plenty of people who prefer significantly longer line lengths because they feel it's more readable that way.
        • dottedmag 7y ago
          Source code is not text, it's all serialized trees and sequences. We don't write code in paragraphs.
  • 7y ago
• cwkoss 7y ago
  Is there a lint-like tool that you would recommend to developers to scan their web application for accessibility issues (and ideally suggest alternative best-practices)? EDIT: found this Web Accessibility Evaluation Tools List with 132 items listed! Anyone have advice on which ones are best? https://www.w3.org/WAI/ER/tools/ https://www.w3.org/WAI/ER/tools/
  • davedx 7y ago
    The lint tool in create-react-app does this out of the box. :)
  • cwkoss 7y ago
    On a related note, our app has a lot of charts. What are the best practices for making time-series graphs accessible? I'd imagine just listing the values wouldn't be particularly helpful for graphs with hundreds or more points - and being able to programmatically summarize the interesting takeaways from an arbitrary chart would probably be useful for our sighted customers as well.
    • spondyl 7y ago
      I’d be interested to hear more about this as well
    • Angostura 7y ago
      Just pondering whether there is a system that converts line graphs into series of rising and falling tones, while a voice reads out the x axis markers. If you have multiple series, you could have different sounds running in parallel - sin wave, square wave or perhaps musical instruments each denoting a different series. That might actually be usable if there was an automated system for creating them on the fly. There's also this kind of approach https://www.youtube.com/watch?v=I9lquok4Pdk https://www.youtube.com/watch?v=I9lquok4Pdk
    • sn 7y ago
      Sarah Newman from prgmr.com here. It's funny you should ask this - we just kicked off an effort a week ago to work on this problem. We don't even have a website yet for the software, but please feel free to watch audiplot.org for future developments.
• gremlinsinc 7y ago
  I'm curious. How do you handle typos in code? Say you're working on a team, and they've got a lot of foreign devs who mis-spell words like color with o u r. Or they just mistype something and leave it... but your screenreader reads it and you hear/know how to spell it so you introduce bugs because you're using correct or localized spellings of a variable name when everywhere else in the code uses the incorrect or other-localized version?
  • hailk 7y ago
    It isn't a mis-spell. Color is used primarily in U. S. Rest of the English speaking world uses colour.
    • gremlinsinc 7y ago
      yeah but my point being if half the team is uk and half is U.S. and you have a blind programmer on each team. You could see where there could be some major nomenclature issues. Of course a good design policy could help, but someone still can mis-spell something, or even just caps in the wrong place. Someone might make: const Sidebar and someone else calls it SideBar. My main question is how do blind programmers deal w/ these sort of issues, I think that would be the hardest thing not being able to see. Hell, I've mis-spelled something before and took me awhile to figure out that was what was breaking things. Of course maybe using statically typed languages and things could help. I'm sure their also tooling I'm unaware of, but definitely curious how they navigate these type of scenarios.
      • exclusiv 7y ago
        I once inherited code written in Spanish and I knew just enough to figure out how to maintain it. Definitely slowed me down a ton but I learned more of a real language while coding! I wouldn't recommend it though for any serious application haha. Back in the day it was on Flash and classic ASP which were both new to me too. Back then you didn't handpick your projects. You just took them and figured them out. I'd attribute a lot of my success from plunging into those types of things.
• bertjk 7y ago
  Have you ever encountered any web sites that you feel went above and beyond in accessibility? I have sometimes wondered while debugging a site for accessibility concerns, fixing the nth input focus problem or what not, whether it would be preferable to actually just design an entirely separate optimized audible experience instead of forcing the user to infer the shape of a designed-for-sighted people website by tabbing all over the place. I imagine that a working implementation would roughly resemble a keyboard navigable phone menu, with the main point being that it would not necessarily correspond to the visual design, but would still offer all of the functionality expected and probably in a more efficient way. Is this a thing? Should it be a thing?
  • mlang23 7y ago
    This approach doesn't work. It has been tried in the past, and almost always produced the same result. The alternative version is not maintained, and after a while you end up with just a small selection of features to be useable for those which use the specially designed version. It will go out of sync, or the specially designed version will never get updated. This is the best way to create a ghetto.
  • playpause 7y ago
    I think one problem with that approach is that blindness isn’t binary. Many registered blind people are partially sighted and use screen readers and other assistive tech to supplement low vision. Another concern: as someone working on a large web development team, I think that maintaining a separate “non-visual” site would entrench a two-tier approach to quality and completeness (noticing and fixing issues, adding new features, etc). If you treat them as two separate applications they will inevitably diverge over time, despite best intentions. You might even end up with slightly different URL structures on each site, making it impossible for a blind user to find the corresponding audio version of a certain URL they found on social media, for example.
    • Angostura 7y ago
      It seems to me that if this ruling is enforced and becomes accepted we may see a welcome move towards 'accessibility first' design - which would be an interesting paradigm shift for many devs.
• deleted 7y ago
  [deleted]
• soulofmischief 7y ago
  Sounds like a pain in the ass. In the case of websites... two years ago I started adopting a11y into my front-end code. But while plugins like eslint-plugin-jsx-a11y make the job easier, it honestly was also a huge pain in the ass familiarizing myself with the grotesque state of affairs in web accessibility standards. However, one of the biggest gains might have been learning to properly leverage every HTML tag to its fullest. Modern day SPAs have all gone back to using wild div forests with no context or metadata available for readers. This also took much less effort than learning the rest of standards compliance. So start there! After crossing that river, I think that accessibility is complex enough to warrant its own dedicated developer for almost any project if standards are to be achieved. Still... until our bosses catch up, we do what we can. Here are some great resources for developers who wish to learn more about how to design for accessibility: https://a11yproject.com/resources/#further-reading https://a11yproject.com/resources/#further-reading P.S. Is it a reasonable heuristic to assume a reader with no visual formatting in their comments might have a good chance of being blind?
  • mwcampbell 7y ago
    > P.S. Is it a reasonable heuristic to assume a reader with no visual formatting in their comments might have a good chance of being blind? As far as I can recall, most of the blind folks on HN don't post big walls of text. Maybe younger blind people who grew up with text-to-speech and never learned braille are more likely to do that. To me, that would be a good reason for screen readers to deliberately pause for a bit between paragraphs.
    • hopesthoughts 7y ago
      Interestingly, I did learn braille. However, I didn't really learn to use paragraphs until 6th grade. Therefore, it doesn't come very naturally to me.
• dlphn___xyz 7y ago
  not trying to be an asshole but how long did it take to type this comment? do you use some sort of voice to text software?
  • Broken_Hippo 7y ago
    To be fair: I can type pretty easily without looking at the keyboard. I am typing this sentence with my eyes closed, even fixing a typo while I do it. Touch typing solves a lot of this and a tab helps to hit the reply button. IIRC, the screen readers will read back texts you just typed as well, but I'm not sure that is as necessary since most folks can get by with typing just fine.
• nazka 7y ago
  Thank you for sharing. For you what are the best resources out there to learn how to do a proper design for blind people or having other disabilities? Also do you have some examples of website done right in UX for blind people? Like for instance I remember using tab on Youtube and they placed a very handy hidden `Skip Navigation` button after 2 tabs that makes navigation faster and easier. Do you have example of that?
• cool-RR 7y ago
  I wonder whether there's a tool that could make websites tactile. Like, a pad with pins that can be programmatically raised and touched, and are used for drawing the website's layout. You could put your hands on it, touch it and feel the layout of the website, scroll around, and eventually click your selection. It can substitute braille font for the font used on the website.
  • rriepe 7y ago
    There's an idea for this called the Braille e-book. I don't think anyone's actually brought one to market, though.
• octocop 7y ago
  I never even thought about this before, you gave me a little eye opener, thank you
• DomreiRoam 7y ago
  The demo part of this video by Tanja Kleut https://www.youtube.com/watch?v=LHgZTeMBihQ https://www.youtube.com/watch?v=LHgZTeMBihQ make me understand better accessibility issues. Without understanding and experiencing, I think it's difficult to really empathize and so the priority to have better accessibility is seen as low.
• Vinnl 7y ago
  Interestingly, the primary surprise in your comment is that you say that just about 20% of website are not accessible - I'd have expected that percentage to be far higher! Of course, there's a difference between "usable" and "easy to use", I guess. As a note, for any sighted developers (like me) reading along: I'd highly recommend you to spend half an hour to learn and practice navigating software with a screen reader some time. It's a relatively easy step that gives you a lot of insight into low-hanging fruit in terms of accessibility improvements. (Also, keep in mind that accessibility is not just vision impairments. Things like small click targets can make things a lot harder for people with motor issues, e.g. many elderly people.)
• tekkk 7y ago
  Hey, thank you for your insight into the life of blind users. I have often wondered if my sites that I've been part of building have been accessible but without proper guidance or customer requirements, nobody has really cared that much to check out. Lately I have been part of building a quite popular website in my native country, and this time, as I have had more autonomy than before, decided to go ahead and add as much accessibility helping markup and proper elements as possible. Eg. everything that can be clicked is now a button (no more divs with onClick-handlers) and by the way, is adding tabIndex to divs even sufficient for triggering clicks? Since by default the Enter-key is not bound to trigger the click-event for elements other than buttons and links (I assume). Anyway, I went ahead and added as much accessibility I could, but some things were bit too much of extra work that I decided not to add them. So I was just wondering, how bad is it when modals don't automatically capture the focus and you can't really travel into them unless moving all the way to end of the document (where the element lies)? From what I glanced from the aria spec, the focus should immediately move into the modal and get trapped where you can only by invoking an action (eg esc-key, click x-button or submit) dismiss them. Also how important are the aria-labels for buttons and such? Should everything worth noticing be annotated? Or can you guess from say the button text what they are for. Also I read somewhere that inputs should always have labels, but sometimes it's problematic to add them eg dates with three inputs with only one label "Birthdate". Can I supplement the label with some aria-property instead? Sorry for asking so many long questions, these things have been on my mind a lot and I really haven't had anyone to tell me if the accessibility fields I have added were correct or not. It's quite annoying how confusing the spec is and how difficult it's to know if the aria properties are correct/make sense or not. Eg how many aria-haspopup etc properties should a dropdown have and which of its elements have which.
  • Tyr42 7y ago
    Not GP, but dev learning a11y too. I'm just going though a web course on this which is pretty good. https://www.udacity.com/course/web-accessibility--ud891 https://www.udacity.com/course/web-accessibility--ud891 I think moving focus into the modal is pretty helpful Here's the video on focus https://www.youtube.com/watch?v=BoAsayPVogE&t=65 https://www.youtube.com/watch?v=BoAsayPVogE&t=65 You can set tabindex="-1" on the header of the dialog, and move focus to that. (Also set outline: none on the dialog, but not anything else). Then you can just call focus() on it, which isn't too hard. I think it's okay if you don't remove the ability to focus on all the background stuff if the focus is at least moved into the modal. I think for aria-labels for buttons, the best way to check this is to either use chromevox/ a screenreader and see what it says for the button. You can also inspect element, and go to the aria tab in chrome dev tools, and see what aria name is computed. You can see the order it takes them from, with aria-labelledby, aria-label, then contents. If the name is reasonable, then you don't need a aria-label at all.
• mdrachuk 7y ago
  To be honest, Domino’s pizza ain’t good. You probably better off this way.
• CommieDetector 7y ago
  Beeing blind does not give you the right to force to make there websites accessible for you.
• m-p-3 7y ago
  Thank you for a glimpse into your perspective. What do you think of the multiple voice assistants out there? Do you think that would be an acceptable alternative or tradeoff if Domino made a bot to take orders?
• magashna 7y ago
  Why wouldn't a blind person just call for a pizza?
  • onion2k 7y ago
    Exactly the same reasons why a sighted person wouldn't.
  • Tyr42 7y ago
    There was also special deals which promoted the use of the online form. Fewer errors from people mishearing you too.
  • hopesthoughts 7y ago
    Lol I do that.
• andrewclunn 7y ago
  Screw off. Its not society's responsibility to bend over for you.
• mumblemumble 7y ago
  As a developer, can you weigh in on why you think it might be hard for small businesses to make their web sites accessible? Are there inherent technical challenges that make it difficult to make accessible websites? Or is it that there's a constant churn of new front-end technologies that typically treat accessibility as an afterthought, and typically leave accessibility as an afterthought that will finally get properly nailed down just in time for the next new technology to come along? Or is it business problems such as the client demanding some overdesigned user experience that can only be accomplished by manually implementing non-standard input elements?
  • mltony 7y ago
    You don't need any non-standard input elements to make web site accessible. In fact the opposite is true: if you only use standard HTML elements, chances are your web-site is going to be fully accessible. It is when developers decide to use some fancy javascript instead of a standard button, or some other fancy form controls, with tons of javascript, this is when screenreaders tend to have problems trying to figure out what's going on. For small businesses I imagine the biggest problem is that they only have only one engineer to support a web site, and he is not familiar with accessibility standards (justifyably so, because there are so few blind people out there), and he'd have to learn these standards and test the web site for accessibility problems - all these actions require time.
    • mumblemumble 7y ago
      Yeah. Sorry for being unclear, but that's what I was thinking: My hunch is that standard HTML elements tend to be accessible almost by default, while non-standard JavaScript-heavy things are more likely to be inaccessible by default. And my other hunch is that using standard HTML elements is actually a less expensive way to build websites. But I'm not sure on that. I haven't touched front end in a long time.
• sargram01 7y ago
  Buttons simply doing nothing happens all the time, sometimes reloading the page makes them work, other times the site is complete broken and it’s time to move on.
• pwg 7y ago
  I have a question for you that I've always wondered about the answer, but I do not know anyone to which to pose the question. How accessible is a basic, plain vanilla, semantic HTML document? I.e., a fully server side rendered HTML doc that uses paragraph and heading and so forth tags for what they semantically mean. Are those type pages accessible, or is more work required to make them accessible?
• hopesthoughts 7y ago
  You really think it's aroun 20% though? I very rarely have problems. Sure learning layouts is interesting, but problems where I flat out can't do something is rare. I'd have to agree that it's more the case when it comes to desktop applications. I'll download something and not be able to use it at all.