4 ms·

When I worked on an accessibility project, we were told that there was a pecking order to the disabilities simply based on how noisy/politically active groups w

When I worked on an accessibility project, we were told that there was a pecking order to the disabilities simply based on how noisy/politically active groups were. If I recall right, the order went: blind, low vision, deaf, motor, color blind, cognitive. I'm sure I'm forgetting a group or two, and motor had a lot of subgroups to care for. Those groups were how we prioritized the work, the blind were always tops. It was interesting how we classed users too in an attempt to be respectful. Blind were 'screen-reader' users. Non-disabled users were called 'sighted' users.

mwcampbell 10y ago
I wonder why that pecking order is the way it is. I'm guessing it's because, before the rise of graphical user interfaces, it was quite easy to adapt computers for blind people. Low-cost (albeit crappy) speech synthesizers were available as add-on cards not long after the beginning of personal computers, and with one of these, writin ga screen reader for a text-based environment like MS-DOS was quite straightforward. And even with the rise of MacOS classic and Windows, developing a screen reader for a GUI primarily required some clever low-level hacking to intercept calls to the OS's drawing functions (e.g. TextOut in GDI) and build a model of what's on the screen. That still seems easier than, say, implementing good speech recognition. So is this pecking order just a consequence of which groups were able to effectively use computers and, by extension, become active online, first? Or is there more to it than that? Do we blind and low-vision people unknowingly do anything to make it worse for people with other disabilities? And can we avoid that?
- fencepost 10y ago
  > I wonder why that pecking order is the way it is. Probably because the web is primarily visual. While there are many things on the web that are less usable if you're deaf, color blind or have motor control or cognitive issues, there are huge areas of it that are inaccessible if you're blind. If I mute my speakers or change my display to greyscale to simulate hearing or color problems I may find that Youtube is a lot less interesting, but if I turn my monitor off I'm going to have a hard time getting to Youtube in the first place. Motor control issues are more likely to be addressable at the user's equipment than at the site level except in ways likely to overlap with visual issues (e.g. keyboard control).
  - EdSharkey 10y ago
    Yes, I think you have it in essence. Motor control issues require web developers to cater to two groups: keyboard-only and mouse-only. Palsies and missing limbs can require the keyboard-only input (careful hunt-and-peck with a controllable arm/finger or stick in the mouth for typing.) Paralysis and lack of fine motor control/accuracy can require mouse-only input systems (eye tracking, big trackpads.)
- EdSharkey 10y ago
  You raise a lot of questions in my mind on this. My knowledge of accessible software history is spotty, especially for pre-web software. Here are some things I was taught that might be helpful: 1) There is a sizeable cohort of blind web surfers even today who operate on ancient, hand-me-down PC's with equally ancient screen readers. The side effect of this is they are stuck on crufty old Internet Explorer 7 or 8 with JAWS from the early 2000's. Web sites might kinda sorta work on these setups, but basically whenever the DOM gets modified on modern single-page webapps, these screen readers can lose the plot and stop reading altogether. WAI-ARIA isn't recognized nor supported by these rigs. 2) Screen-reader users that are skilled and savvy can crank the reading speed up on their screen readers to ludicrous speed. A well-architected page can be scanned and read to a screen-reader user at a rate comparable to a sighted user's reading rate. The combination of these two things, I think, can make web technology tantalizingly-but-not-quite accessible for the blind. Meaning, a website can provide a passable experience or a torturous one depending on how clued-in the developers were when they built the page. A few missing alt attributes or absolutely positioned DIV's, and the page reads like nonsense, even on modern screen readers. I have personally watched a screen-reader user somehow get himself into a loop, essentially racing around the top, right, and bottom nav's of a badly designed page with their screen reader and never getting into the body of the page. I would go bonkers if I were that guy; he just wanted to pay his utility bill and he couldn't get to the crummy form that was buried somewhere in the (probably malformed) HTML on the page. This leads me back to your questions: > Do we blind and low-vision people unknowingly do anything to make it worse for people with other disabilities? And can we avoid that? Worse? No, I don't think so, not in my experience at least. The various disability groups have wildly differing inherent strengths, weaknesses, and operating speeds. I think blind peoples' potential to race around a page with a screen reader and consume the data on it at a near sighted user pace simply drives them to advocate more strongly for themselves than other disabled groups. It goes even to the point that lawsuits are being filed to improve the accessibility on some public utility websites. These lawsuits were filed specifically to get the sites to be WCAG 2.0 Level AA compliance. It was very clear those lawsuits were to serve the blind plaintiffs, and my team's prime directive was to get the page to read equivalently to the screen reader users and sighted users. But, of course getting WCAG 2.0 Level AA compliance is also going to encourage us to provide for low vision, motor, and color blind users' needs as well. So, I figure everyone wins when the blind folks get their way. :) On the other end of the navigation speed spectrum, you have low vision and motor users. You wouldn't believe how challenging it is for low vision users to fill out forms on poorly designed pages. Often they have to have magnification cranked so high that only a couple letters in a word are visible on the screen. For them to even find form fields on a badly laid-out form takes a heroic effort. I'm not a fan of right nav's for this reason; it's sometimes incredibly painful for a low vision user to discover that controls or (worse yet) an HTML form needed to get work done is a million miles over to the right hand side of the page. I have heard that low vision users can will go through the torture of filling out a form, finally locate the submit button, click it, and then learn that their session timed out because they spent too much time on that page between clicks! There are websites with 30 minute session cookie timeouts that had to be cranked to an hour so that these users wouldn't suffer timeouts. And Lord help them if they mistyped anything or had some other form error - then they have to do the painstaking search for red text or error messages to find out what their problem was. PAIN!! You might think that a low vision user could just tab around between links and fields, but that doesn't work as they get hopelessly lost. For them to navigate a page, they literally must scan by scrolling around their pinhole of a viewport and build up a mental model of where things are at. My personal design theory is that forms should be laid out along a single "axis" running the length of the page that is easy for the low vision user to stumble across and "ride" up and down as they build their mental map of the page. Of course, savvy low vision users can combine magnification with a screen reader, and those users do just fine. Screen reader gives them text and forms and magnifiers let them hunt down and ogle the pictures.

mwcampbell 10y ago

I wonder why that pecking order is the way it is. I'm guessing it's because, before the rise of graphical user interfaces, it was quite easy to adapt computers for blind people. Low-cost (albeit crappy) speech synthesizers were available as add-on cards not long after the beginning of personal computers, and with one of these, writin ga screen reader for a text-based environment like MS-DOS was quite straightforward. And even with the rise of MacOS classic and Windows, developing a screen reader for a GUI primarily required some clever low-level hacking to intercept calls to the OS's drawing functions (e.g. TextOut in GDI) and build a model of what's on the screen. That still seems easier than, say, implementing good speech recognition. So is this pecking order just a consequence of which groups were able to effectively use computers and, by extension, become active online, first? Or is there more to it than that? Do we blind and low-vision people unknowingly do anything to make it worse for people with other disabilities? And can we avoid that?

fencepost 10y ago
> I wonder why that pecking order is the way it is. Probably because the web is primarily visual. While there are many things on the web that are less usable if you're deaf, color blind or have motor control or cognitive issues, there are huge areas of it that are inaccessible if you're blind. If I mute my speakers or change my display to greyscale to simulate hearing or color problems I may find that Youtube is a lot less interesting, but if I turn my monitor off I'm going to have a hard time getting to Youtube in the first place. Motor control issues are more likely to be addressable at the user's equipment than at the site level except in ways likely to overlap with visual issues (e.g. keyboard control).
- EdSharkey 10y ago
  Yes, I think you have it in essence. Motor control issues require web developers to cater to two groups: keyboard-only and mouse-only. Palsies and missing limbs can require the keyboard-only input (careful hunt-and-peck with a controllable arm/finger or stick in the mouth for typing.) Paralysis and lack of fine motor control/accuracy can require mouse-only input systems (eye tracking, big trackpads.)
EdSharkey 10y ago
You raise a lot of questions in my mind on this. My knowledge of accessible software history is spotty, especially for pre-web software. Here are some things I was taught that might be helpful: 1) There is a sizeable cohort of blind web surfers even today who operate on ancient, hand-me-down PC's with equally ancient screen readers. The side effect of this is they are stuck on crufty old Internet Explorer 7 or 8 with JAWS from the early 2000's. Web sites might kinda sorta work on these setups, but basically whenever the DOM gets modified on modern single-page webapps, these screen readers can lose the plot and stop reading altogether. WAI-ARIA isn't recognized nor supported by these rigs. 2) Screen-reader users that are skilled and savvy can crank the reading speed up on their screen readers to ludicrous speed. A well-architected page can be scanned and read to a screen-reader user at a rate comparable to a sighted user's reading rate. The combination of these two things, I think, can make web technology tantalizingly-but-not-quite accessible for the blind. Meaning, a website can provide a passable experience or a torturous one depending on how clued-in the developers were when they built the page. A few missing alt attributes or absolutely positioned DIV's, and the page reads like nonsense, even on modern screen readers. I have personally watched a screen-reader user somehow get himself into a loop, essentially racing around the top, right, and bottom nav's of a badly designed page with their screen reader and never getting into the body of the page. I would go bonkers if I were that guy; he just wanted to pay his utility bill and he couldn't get to the crummy form that was buried somewhere in the (probably malformed) HTML on the page. This leads me back to your questions: > Do we blind and low-vision people unknowingly do anything to make it worse for people with other disabilities? And can we avoid that? Worse? No, I don't think so, not in my experience at least. The various disability groups have wildly differing inherent strengths, weaknesses, and operating speeds. I think blind peoples' potential to race around a page with a screen reader and consume the data on it at a near sighted user pace simply drives them to advocate more strongly for themselves than other disabled groups. It goes even to the point that lawsuits are being filed to improve the accessibility on some public utility websites. These lawsuits were filed specifically to get the sites to be WCAG 2.0 Level AA compliance. It was very clear those lawsuits were to serve the blind plaintiffs, and my team's prime directive was to get the page to read equivalently to the screen reader users and sighted users. But, of course getting WCAG 2.0 Level AA compliance is also going to encourage us to provide for low vision, motor, and color blind users' needs as well. So, I figure everyone wins when the blind folks get their way. :) On the other end of the navigation speed spectrum, you have low vision and motor users. You wouldn't believe how challenging it is for low vision users to fill out forms on poorly designed pages. Often they have to have magnification cranked so high that only a couple letters in a word are visible on the screen. For them to even find form fields on a badly laid-out form takes a heroic effort. I'm not a fan of right nav's for this reason; it's sometimes incredibly painful for a low vision user to discover that controls or (worse yet) an HTML form needed to get work done is a million miles over to the right hand side of the page. I have heard that low vision users can will go through the torture of filling out a form, finally locate the submit button, click it, and then learn that their session timed out because they spent too much time on that page between clicks! There are websites with 30 minute session cookie timeouts that had to be cranked to an hour so that these users wouldn't suffer timeouts. And Lord help them if they mistyped anything or had some other form error - then they have to do the painstaking search for red text or error messages to find out what their problem was. PAIN!! You might think that a low vision user could just tab around between links and fields, but that doesn't work as they get hopelessly lost. For them to navigate a page, they literally must scan by scrolling around their pinhole of a viewport and build up a mental model of where things are at. My personal design theory is that forms should be laid out along a single "axis" running the length of the page that is easy for the low vision user to stumble across and "ride" up and down as they build their mental map of the page. Of course, savvy low vision users can combine magnification with a screen reader, and those users do just fine. Screen reader gives them text and forms and magnifiers let them hunt down and ogle the pictures.