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 varies somewhere from 20% (for web sites) to 50% (for desktop applications). That's just my approximation of the state of accessibility these days.
Now imagine that you live in the world where you don't know which printer or wi-fi router to buy, since maybe half of them you won't be able to use.
Imagine that you cannot order from some online stores. You cannot fly certain airlines. And apparently you cannot order some pizza online.
Worst of all you don't magically know whether a web site is accessible or not. You just go to web site and try it, spend some time to learn the layout - it typically takes blind peple longer to familiarize with new web sites, spend thirty minutes to fill out the details of your order and then when you try to click the submit button, you figure out that it wouldn't click for some reason. Being a developer you open HTML code just to realize that this is some weird kind of button that can only be clicked with the mouse, but not a screenreader. But hey, your screenreader can route the mouse cursor to this button and simulate a click. So you try a real mouse click and it still doesn't work for some reason, and I have no idea why. Finally, you give up.
I hope I managed to convey a typical sense of frustration with a web-site that is not that accessible. I do get arguments of other people that it might be hard for small businesses to make their web sites accessible. and I don't know where to draw a line, but I need to say that Domino's is a large enough company and even though I hate counting other companies' money, I must say they're big enough to be able to afford to make their web-site accessible.
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?
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.
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.
I would welcome 'accessibility first' if it means people start thinking about 'semantics' again. 10-15 years ago, the web dev world was obsessed with semantics, separation of style and content, the idea you could just edit CSS to do a complete redesign (like csszengarden.com), and your markup could remain untouched, understandable by all devices present and future. I think this notion still holds some power, but it's obviously taken a hit with the component paradigm. The modern approach of 'sprinkle-on' accessibility doesn't work as well, and just feels like a messy extra step you have to do when building a feature. It was much better when people cared about baking it in from the ground up, through considered semantics and document outlines.
> it's obviously taken a hit with the component paradigm
Can you please explain how the component paradigm is at odds with semantic markup? Is it just that developers are now satisfied with the semantics being in their component names and props, and don't care if it actually gets rendered as undifferentiated divs?
My own hypothesis is that React gave developers permission to question some things that were previously deemed sacred in web development, and developers went too far with that. Using a component framework like React or Vue is not inherently at odds with producing good semantic markup.
> Is it just that developers are now satisfied with the semantics being in their component names and props, and don't care if it actually gets rendered as undifferentiated divs?
Basically, yes. Also, components often require extra div-nesting for robustness, and then there's the obfuscated classnames (CSS-in-JS), and the way responsiveness tends to be done these days (crude media query helper components that show/hide duplicated subsections of DOM for different devices). This all means the rendered DOM in devtools is bloated and hard to read anyway, so there's less point in caring about keeping it nice and clean.
Also, if you're mostly focused on building individual components, you probably don't feel as much ownership over the page as a whole, so you don't think about how your rendered DOM affects the document outline. Without that bigger picture, semantics isn't as interesting.
I think the United States Web Design System might fit in that category. It's made by the US Digital Services, and describes itself as "A design system for the federal government. We make it easier to build accessible, mobile-friendly government websites for the American public."
It's a well thought-out framework and from what I've read, accessibility was taken into account in the very first stage of the redesign of the new V2
That kind of markup may also be useful for software analysis. Parsing prose is becoming tractable. Maybe Alexa or the (nameless) Google Assistant will be able to order the pizza for you. They're supposed to be able to do it over the phone.
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.
Microsoft does a TON of work to make it's applications not only accessible, but user friendly to screenreader and keyboard users.
This is most obvious in the OneDrive online. The selectable list of files is implemented using Layout Grid, and thus is a single tab stop. Arrow keys can be used to navigate the grid and inline actions, and it's a single SHIFT-TAB to navigate up to the multi-selection actions.
There's ARIA controls and interactions that are defined in such a way that a non-sighted user can just hear what "type" of interaction it is and already know how to navigate it.
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.
I appreciate this feedback, I'll keep it in mind for my future comments.
And by the way, it is very common that people can't find words to give me feedback - happens pretty often. So I encourage people to give me feedback - no need to feel like ass :)
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/
> 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.
If you make your browser window half width, or increase your text size, you may find it's easier to read. When I'm awake and focused, I can read smaller text across longer lines without problems. When I'm more tired, I need to increase the text size, bring the screen closer, make window widths smaller.
You may also benefit from getting your vision checked. This may be early stages of something occurring, and the sooner it's identified the better.
There's other cognitive issues here. I find reading from the screen difficult, CRT, LED, OLED, but I'm fine given e-ink. Any web pages with text more than a paragraph or so is sent to an e-reader for me, otherwise I just cannot comprehend the content. I can cope with snippets.
The problem isn't line spacing whatsoever, it's tracing which one of the 10 lines you are reading from one side of a screen to another as your read it.
Did you make your comment 3 paragraphs ironically?
> The problem isn't line spacing whatsoever, it's tracing which one of the 10 lines you are reading from one side of a screen to another as your read it.
Then make your window less wide. It's not the writer's problem.
> Did you make your comment 3 paragraphs ironically?
No, but I don't think it would be hard to read if it was one paragraph. That formatting is to add in small pauses, not to make it easier to read when lines wrap.
Are you arguing that, or offering it as a potential argument? § That's not what mrep claimed made it hard to read. They said it was hard to trace lines. § And there are other ways of adding pauses, on top of those pauses not being very necessary in the first place. I could do without them just fine. § More generally, as long as a big paragraph is focused on one topic, and nobody is doing a point-by-point reply, it works just fine.
I am arguing that, and it's also how I read mrep's comment: it's a wall of text with no clear pauses, making it hard to read.
And if those §'s are your other ways of adding pauses, then those are entirely insufficient for inserting pauses for most readers, including me: we're not trained to read those characters as pauses.
Sure, there might be other ways. But they're not applied, making the comment harder to follow for some people than it would be had it been subdivided into paragraphs, and mrep was merely helpfully pointing that out in case mltony wanted to keep those people in mind in the future.
But good for you that you're not one of those people, I guess.
> those are entirely insufficient for inserting pauses
Pretend I said "indicator of separation" instead of "pause" then.
> Sure, there might be other ways. But they're not applied, making the comment harder to follow for some people than it would be had it been subdivided into paragraphs, and mrep was merely helpfully pointing that out in case mltony wanted to keep those people in mind in the future.
By talking about "other ways" to mark a logical separation, I think you're on a completely different argument than mrep. mrep is saying that it's physically hard to track the lines when reading, which is entirely a function of line length and spacing. mrep's problems would be solved if I started adding newlines in the middle of sentences, even though that would make things worse in terms of subdividing into coherent paragraphs.
Then I think we have a different interpretation of mrep's point. (Where my interpretation has going for it that mrep themselves isn't even doing what you're saying they want.)
> Then make your window less wide. It's not the writer's problem.
Exactly. Not all we want and need to tell other people can be reduced to tweets. whoever has the windows maximised on a desktop has another option, and the paragraph was never a 140 character slogan.
It’s the opposite: if you insist on keeping your browser maximized that can mean that you probably need all the width on some other site which scales poorly.
As a reference, I maximize my browsers when I'm using developers tools or when I'm using pseudo desktop web apps, usually customer mandated. I'm thinking about Kanbanize, Trello, almost all of Google, Travis, etc. Apps that display a lot of information.
HN and other text based sites are more readable in narrower windows or on a phone.
HN on a phone suffers when comments are deeply nested (this one) and when somebody quotes text using spaces as of it was a block of code.
Just tried out Tree style tabs, how does this prevent this issue? I have two pages in two tabs open. To read one I resize the window, I go to the other it has been resized also.
I have such bad eyesight that I gave up my driver's license. I didn't find it that burdensome to read the comment in question.
You might want to get your eyes checked or read up on other disabilities that can impair reading ability even if your eyesight is fine. If you feel so impinged upon that it makes sense to you to ask a blind person to accommodate your needs and problems, you may have an unidentified handicap.
So the GP volunteers unasked for feedback and that's cool. I do the exact same thing they did and somehow that makes me the asshole?
I already covered the fact that tracking problems can be due to reasons other than poor eyesight. I even provided supporting links for that assertion.
Part of my background is working for an educational organization that catered to the needs of gifted kids, including twice exceptional kids. It was common for early readers to have tracking problems and for parents to share practical tips on how to cope, as well as talk about at what point to get concerned and get the kids checked for something else.
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
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?
> 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.
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?
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.
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.
Highcharts has put a lot of effort into designing charts to be accessible. They did a presentation about it at my workplace a few months ago and I was impressed by the passion and level of user testing they had done.
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.
My team at Microsoft maintains an open source browser extension for this called Accessibility Insights (https://accessibilityinsights.io), which is what Microsoft recommends internally for its own teams developing websites.
It offers a fast 5 minute scan for some of the most common/easily detectable issues, and also a much fuller assessment with a mix of automated checks and guided/assisted manual tests that aims to help web developers who aren't accessibility experts achieve full WCAG 2.1 AA compliance.
I use https://khan.github.io/tota11y/ which you can add to your browser to run through your site. I also sometimes just close my eyes and run a screen reader through a site to see if I could navigate it reasonably. Neither of these options helps with catching everything but they're better than nothing.
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.
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...
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.
I wanted to work on it, I even have a domain for it bought already, though other things in life, procrastination among them, stopped me for now. I will do it someday, though.
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/
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 ;-)
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.
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.
I actually work more in backend area, so I am not that familiar with accessibility standards in HTML. I am only a user there. But looks like others have already answered some of your questions.
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?
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?
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.
> 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.
A. Whoever has the most $$, or B. (More likely), whoever is in charge of the element/component that is blocking accessibility. Since recaptcha is an embed that would be Google.
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.
> 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.
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.
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.
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.
Just to agree with the other's reply here: I am not blind, but do touch typing. Sometimes I don't even look at the screen or keyboard since I've learned to copy things (Such as a paper I've written by hand). You do get to a point where you develop a "sense of typo" and can simply correct the mistake.
It has its limitations: It doesn't help you spell better, only correct typing mistakes.
Typing class expected me to look at the sample I was typing, not at my own output. Being able to accurately type without looking at your output is a standard expectation for sighted people.
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.
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.
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.
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.
Yep when I was doing accessibility dev, that was exactly how I tested. It's pretty effective and it also gives you a feel for how crappy the tools are for the blind.
If you use Windows, I suggest NVDA - it's a free screen reader that's similar to the most-popular-but-expensive one (JAWS):
https://www.nvaccess.org/download/
IMHO the best screen readers are on your phone / tablet. This might sound crazy (how can a touchscreen work when you can't see it?) but they're much better designed than their desktop equivalents. Mobile software tends to be simpler, resulting in a better experience:
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.
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.)
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?
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.
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.
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.
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?
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.
The demo part of this video by Tanja Kleut 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.
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.
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.
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!
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?
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.
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/. Chromevox and Voiceover can be turned on to get quick screenreader-ish feedback.
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/ 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.
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.
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?
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?
It depends. If I know I'll make an order only once, calling phone is probably easier. If that's a pizza, and say I have expectation that I might be ordering same pizza every week or every month, then ordering through website is easier, since you can save your credit card information there instead of repeating it on the phone every time.
But even for one-time orders it is good to have an accessible site, since what I mentioned above - I would waste my time if the web site is not accessible. I assume if they had put a notice on their web site saying that it is not accessible for screenreaders - please call this number instead - that would be already a better solution rather than just an inaccessible web site.
From another angle here, I occasionally have problems that make me use a screenreader.
When the nerves that make my eyes work stop behaving correctly, it's also normal for the nerves in my throat to flip out so that speaking feels like breathing razor blades.
Making a call isn't an option, but using a web browser still is, if they haven't gone out of their way to break all the ways a web browser is supposed to behave.
Same. I have severe convergence insufficiency (that is highly variable and cannot be corrected, from a practical standpoint) due to a rare immune-mediated neurological disease.
I either use Kurzweil 3000 (Windows|Mac|Browser) (paid)|JAWS (Windows) (paid)|Voice Dream Reader (iOS|Android)| VoiceOver (iOS) (free)| Talkback (free), depending on what I am doing and how my much my eyes are affecting me at that moment.
I taught myself braille and I have a couple of refreshable braille displays, which I use, depending on how well my eyes are working.
I can digitize printed material well, including STEM material, using a program called InftyReader (Windows).
It is no fun, but you have to do what you have to do.
Blind people are the same as everyone else, but with reduced vision. So when you ask "Why don't blind people just call?" you actually need to be asking "Why don't I just call?" Blind people will have the same reasons.
Most people I know prefer to use an online system to avoid talking to people especially if there's a complex process or lots of information to enter. Blind people feel the same way. A phone based option is not "offering the same service" to blind people.
If there was an online system that only worked with screen readers and the company said "sighted users can just call instead" I wouldn't use that company, and if they had the best price offering I'd be very annoyed. Making an inaccessible website is exactly the same.
I’m not blind. But I would be furious if I had to call to place an order rather than submit a web form, merely because the site couldn’t be bothered to adhere to basic standards and instead used meth-addled “code artisans” practicing resume-driven development.
Coming from somebody who is disabled: this is what life is like for a disabled person.
There are many, many indignities that we encounter, even nearly constantly due to the way society ignores our needs.
If you go and check out some disabled activists' Twitter accounts, you may be shocked at the anger and the lack of "decency". But, put yourself in their shoes, and realize that they have been forced to deal with systematic and near-constant indignities, and many of them have been forced to fight for their mere existence as human beings.
I agree with such activists. It's stupid to have to make a phone call when a website should be perfectly capable for this role.
While I don't claim to know what such disabilities are like, I feel I have experienced analogous frustrations. Back when Linux on the desktop and Firefox were catching on, I remember it being a crapshoot about whether critical sites (like banks and tax filing) would play nice with non-IE browsers, and I had to have a PC/Windows/IE setup as a fallback. Same issue: the use the meth-addled design that breaks any non-mainstream clients.
I also use Tridactyl (and before it, Vimium and pentadactyl), an extension that lets you click links from the keyboard, which is a huge UI improvement and (along with other keyboard input methods) speeds up web browsing significantly. It's generally good at detecting links, but the same sloppy design and over-clever features make clickable elements undetectable and frustrate this enhancement.
And for the kicker ... often times, these improvements "for the disabled" end up benefiting everyone else even more, but designers/buisdev people don't get it! See my previous comment about the Curb Cut Effect [1].
The web was designed with screen readers in mind. It is a serious regression to find major sites telling blind users to call in. This isn't the 60s.
Are those standards sufficiently complete as to be referenced by regulatory agencies?
If so, what's keeping us from adopting standards or at least recommendations for legal compliance?
I think that Domino's assertion is that the current framework is too vague, but I regularly see the argument that there are standards to follow. So... What are those standards, and why aren't they law?
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.
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.
It was $5 cheaper than regular menu price. But he ordered a literal 100 times a year with the coupon, tipped the delivery driver $5 every time and the order still was more profitable than $15 of chicken wings.
Once the coupon left, he went to the competition. I used to spend about $1,000 a month in advertising just to get a few new customers to call. Keeping the ones you have is orders of magnitude cheaper, even if they complain about "cold pizza" once a month or so to get a free pie.
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?
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.
Yeah, I worked a lot on software written by russians, ukrainiens and chinese; basically the software has no usable comments for me (translation software was not helpful back then) and a lot of variable and method names were wrongly spelled english or ascii (not cyrillic etc) written russsian etc. It had a solid feeling of being obfuscated code a lot of the time. Fun times.
It’s reasonable to standardise on a flavour of English that you want your code and comments to be written in. For some teams, that’ll be US English and all developers should be expected to abide by that standardisation. For other teams it’ll be British English and US developers would be expected to meet the common coding standard too.
Screen readers are modal and I believe e.g. JAWS has a character-by-character mode to spell out the character that's under the cursor. Aside from that, from what I saw in a conference presentation, sight impaired users can use tools like Intellisense.
