When I was working on a team with an accessibility requirement. The bulk of the work wasn't coloring work, nor writing alternative texts, but ensuring that the website could be navigated well using a screen reader.
We used JAWS[0] and tested every change and new feature with it to ensure users of it could make sense of the website. This was a lengthy process that took a lot of effort and learning on the part of devs to pick up JAWS.
The tough part of it was it being a subjective process. No one can tell you if the final experience was "correct" or not.
This part of web accessibility isn't mentioned as often, but its just as important. Likely because not many people really know about it.
Edit: I think part of it is the high cost of products like JAWS. The current price of a home license is $1,000. A business license is $1,285.
Most accessibility shops and devs tend to use the free NVDA screenreader[0] for accessibility testing because of the costs associated with JAWS.
There are differences between the two (and the other well used screenreader VoiceOver) but NVDA is a damn good product with a decent user base that certainly helps in finding potential hiccups in complex frontend applications. Usually this happens when one of the screenreaders hits something on a webpage that triggers 'interaction mode'[1]
Edit: Interestingly the most recent data I found[2] seems to indicate that NVDA has passed JAWS as the most used screenreader, so might be worth using as the default for testing
1. >>> but ensuring that the website could be navigated well using a screen reader. <<<
That was my experience too
2. >>> The tough part of it was it being a subjective process. No one can tell you if the final experience was "correct" or not.<<<
Also ran into this problem. Our solution was to hire a non-sighted person (who uses screen reader in their daily/everyday life) to test the Apps. It made me realize that 'expert' users of screen reader software do not use it the way a sighted user like me would think it's to be used.
3) We only use the non-sighted person when we do 'major' overhauls or once every few years when we do a comprehensive round of Accessibility testing. For the accessibility tests we do as part of releasing any new feature (no matter how small), I've had to train myself and learn better how to do screen reader testing. Still not close to being an expert but I'm much better at it than a few years before.
I went on Facebook and looked for JAWS support and user groups.
I posted a polite request for volunteers to participate in a user study of foss community building software. A couple of volunteers came forward.
I supplied them with a URL to a standard build and a list of tasks covering the basic feature set -- read topics list, find particular topic, particular user, apply tags, register, post something under account, sign out, look up stats.
Because I had already tested with Netscape, IE, textmode, NoJS, keyboard-driven, and because I'd already conducted several revealing user tests with novice users, the screen reader tests passed with flying colors on the first try and with no reported issues.
That doesn't mean my work is done, and I'll have to keep re-testing as I continue development. However, I think it illustrates well the benefit of trying to support not just 10% browsers, and not just 1% browsers, and not just 0.1% browsers, but every single configuration you find or can imagine.
Of course, if your goal is development speed and such, the top most common refrain I hear when presenting this point of view, this may not work for you, and I wish you the best of luck, it's not for everyone.
But if you're writing for longevity and accessibility, this is the routr I'd recommend.
I'm sorry to hear that it was a lengthy process for your team. What do you think took more time: learning to use the screen reader, or fixing your site?
This article isn’t all bad, but it’s not particularly high quality either.
<img src=”baby_elephants.png” alt=”A group of two baby elephants walking behind their mom in a open field.”>
… followed immediately by a demonstration baby elephant image with empty alt text (which in a case like this is worse than no alt attribute, because it tells accessibility tech that the image is purely decorative and should not be announced).
(Note also the use of ” instead of ".)
This is not encouraging.
> You can add a landmark by using the role attribute. Some examples of landmarks are banner, form, and search. Something to note is that you should only place the role attribute on elements like <div> and <span>, do not place on elements that have semantic meaning like a <ul> or <p>.
There is nothing wrong with overriding the role of an element with semantics; it purely comes down to whether you do it correctly. And the thing that they don’t mention here is that the converse applies at least as much: if there’s a built-in element with your desired semantics, you should use that instead of a role, so the example is a bad example: its <div role="navigation"> should be <nav>.
If you prefer reader mode, like I do, any Medium-based platform is a PITA cause all images are blurred. Anyone who is on a crappy connection will have them same. What a fuxxing shame! Can we stop using this crappy platform please?
Let’s, but really do you care about the images or are you there for the article content :) reader mode is nice to skip the silly “pardon the intrusion” or “sign up to our newsletter spam” modals, and i don’t think I’ve ever missed any photos or images when reading stuff like that. These days I tend to just avoid content on medium.
One problem here: line height should be unit-less. Use just a number and that number will become a multiple of the font value so font-size 2rem line-height:1.3 don’t use units
This was a major stumbling block for me until I read about it on MDN. My blog's longish titles were always spilling over into the next line until I removed the em unit. Serves me right for not RTFM-ing and thinking I know enough HTML to cobble together a basic site.
Something not mentioned that a ton of modern websites fail at is having readable text due to either too-low contrast, too-thin or too-small fonts, or all of those things combined. These days it seems like I have to use reader mode for half the articles or blog posts I read daily.
[+] [-] Jaygles|5 years ago|reply
We used JAWS[0] and tested every change and new feature with it to ensure users of it could make sense of the website. This was a lengthy process that took a lot of effort and learning on the part of devs to pick up JAWS.
The tough part of it was it being a subjective process. No one can tell you if the final experience was "correct" or not.
This part of web accessibility isn't mentioned as often, but its just as important. Likely because not many people really know about it.
Edit: I think part of it is the high cost of products like JAWS. The current price of a home license is $1,000. A business license is $1,285.
[0] https://www.freedomscientific.com/products/software/jaws/
[+] [-] steerpike|5 years ago|reply
Edit: Interestingly the most recent data I found[2] seems to indicate that NVDA has passed JAWS as the most used screenreader, so might be worth using as the default for testing
[0] https://www.nvaccess.org/about-nvda/ [1] https://tink.uk/understanding-screen-reader-interaction-mode... [2] https://webaim.org/projects/screenreadersurvey8/
[+] [-] nocommandline|5 years ago|reply
That was my experience too
2. >>> The tough part of it was it being a subjective process. No one can tell you if the final experience was "correct" or not.<<<
Also ran into this problem. Our solution was to hire a non-sighted person (who uses screen reader in their daily/everyday life) to test the Apps. It made me realize that 'expert' users of screen reader software do not use it the way a sighted user like me would think it's to be used.
3) We only use the non-sighted person when we do 'major' overhauls or once every few years when we do a comprehensive round of Accessibility testing. For the accessibility tests we do as part of releasing any new feature (no matter how small), I've had to train myself and learn better how to do screen reader testing. Still not close to being an expert but I'm much better at it than a few years before.
[+] [-] forgotmypw17|5 years ago|reply
I posted a polite request for volunteers to participate in a user study of foss community building software. A couple of volunteers came forward.
I supplied them with a URL to a standard build and a list of tasks covering the basic feature set -- read topics list, find particular topic, particular user, apply tags, register, post something under account, sign out, look up stats.
Because I had already tested with Netscape, IE, textmode, NoJS, keyboard-driven, and because I'd already conducted several revealing user tests with novice users, the screen reader tests passed with flying colors on the first try and with no reported issues.
That doesn't mean my work is done, and I'll have to keep re-testing as I continue development. However, I think it illustrates well the benefit of trying to support not just 10% browsers, and not just 1% browsers, and not just 0.1% browsers, but every single configuration you find or can imagine.
Of course, if your goal is development speed and such, the top most common refrain I hear when presenting this point of view, this may not work for you, and I wish you the best of luck, it's not for everyone.
But if you're writing for longevity and accessibility, this is the routr I'd recommend.
[+] [-] loloquwowndueo|5 years ago|reply
Does it even show in your radar, compared to JAWS?
I need to fix a site to work with Orca and it would be nice if that also made it be friendly to JAWS users, but I know next to nothing about either.
[+] [-] mwcampbell|5 years ago|reply
[+] [-] chrismorgan|5 years ago|reply
(Note also the use of ” instead of ".)
This is not encouraging.
> You can add a landmark by using the role attribute. Some examples of landmarks are banner, form, and search. Something to note is that you should only place the role attribute on elements like <div> and <span>, do not place on elements that have semantic meaning like a <ul> or <p>.
There is nothing wrong with overriding the role of an element with semantics; it purely comes down to whether you do it correctly. And the thing that they don’t mention here is that the converse applies at least as much: if there’s a built-in element with your desired semantics, you should use that instead of a role, so the example is a bad example: its <div role="navigation"> should be <nav>.
[+] [-] indysigners|5 years ago|reply
[+] [-] oehtXRwMkIs|5 years ago|reply
[+] [-] loloquwowndueo|5 years ago|reply
[+] [-] brainlessdev|5 years ago|reply
[+] [-] JoeCianflone|5 years ago|reply
[+] [-] approxim8ion|5 years ago|reply
[+] [-] Narishma|5 years ago|reply