(my reply wound up over 8kb long, but I don’t think it’s general enough to turn into a discussion article.)
Reading this and its comments immediately made me think of the current status of braille, where technology has completely failed to keep up with the mainstream, and now many people are claiming that braille is outdated and they’ll just use text-to-speech for everything. (Disclaimer: I was taught braille starting from kindergarten, and picked it up fast and thoroughly. A lot of anti-braille people appear to have had a very hard time learning it and can’t actually read any quicker than I could read large print when my vision was at its best. So I have to acknowledge some kinda privilege when talking about the subject. I’ll also acknowledge that mastery of braille and financial/academic/etc success are positively correlated among blind Americans, according to all the not-incredibly-transparent sources I’ve found.)
Some of the points made here about text in general apply to braille, some are just the opposite, and some depend entirely on the audio/video/tactual affinities of the specific user. For example:
•You can’t play background music while having a video conversation or recording audio or video content.
Is one of the arguments I use in favor of braille whenever the subject comes up, and it’s easily extended to consumption: noise and reading, noise and writing, privacy, the need/lack for headphones, all the different environments in which one can work, etc.
This, though:
•Low storage and bandwidth costs make it easy to consume over poor Internet connections and on a range of devices.
Is only technically true for braille, since braille technology is so far behind that devices are almost always bulky, expensive, cumbersome, in addition to the mainstream device to which they connect, and only the most expensive and bulkiest models display more than 40 characters at a time (so like half of one print line… and most people will get an even smaller model, because even 40 characters is bulky, expensive, and generally more than trivially inconvenient to use on anything but a dedicated device like the PACMate Omni). The base format, digitally, is the same and can be transmited and stored easily, but everyone who can hear but not see is going to convert it to speech anyway.
•Text can be read at the user’s own pace. People who are slow at grasping the content can take time. People who are fast can read very quickly.
Applies to text-to-speech as well; most TTS has adjustable speaking rates, and it’s possible to go back and reread things (however, checking the spelling of words is a trivial inconvenience which almost no one that relies on a TTS ever uses. Ever seen me misspell something? That’ll be why. On the other hand, what types of errors count as obvious visually vs obvious audibly differ, so blind and sighted text speak tend to differ simply for readability’s sake.).
•Text is easier to search (this refers both to searching within a given piece of text and to locating a text based on some part of it or some attributes of it).
Even people who don’t care for braille in general will agree that it helps loads with math and programming for exactly this reason. If hooking a braille display to a laptop were not so bloody inconvenient (and did not require so much desk-space), I’d have one connected pretty much all the time for this alone.
•You can’t play background music while consuming audio-based content, but you can do it while consuming text.
People usually reply to this with “Use the Windows volume mixer.” (I disagree with said reply under most conditions. If I have to have music quieter than a screen reader, then a lot of the impact is reduced. And screenreader + conversation is just plain impractical.)
On the flip side, reading text requires you to have your eyes glued to the screen, which reduces your flexibility of movement. But because you can take breaks at your will, it’s not a big issue.
Depending on the device, the opposite can be true for braille; a small display, or something smaller than a novel (braille novels are enormous) can be read while walking without compromising one’s awareness of one’s surroundings (especially if one can read one-handed). Audio is dependant on the device as well, however; walking around with bulky headphones on is a terrible idea (compare texting while driving), but external speakers while going about other business in the same room is fine.
The presence of hyperlinks, share buttons, the occasional image, sidebars with more related content, etc. add a lot of value.
Braille does not do formatting well, but neither does audio, and I’ve never had access to a braille device that can actually perform the equivalent to clicking or tapping a hyperlink. This is an improvement I thought of the first time I actually had a braille display for more than 5 minutes: every braille display I’ve ever seen includes cursor-routing keys, which are basically buttons above each cell that will move the cursor to that position when clicked. The obvious thing to do is to double-click one of those to simulate a mouse-click at that spot, yet I’ve never heard of this being implemented.
There’s also such a thing as 8-dot braille, which is typically used for unicode characters, to indicate capitalization, or to indicate the position of the cursor or highlighted text. Even most braille-using techies don’t learn 8-dot unicode (and from what I can tell, that isn’t even standardized, so it’d only matter for the specific hardware/software combination that one studied with), so it’s a little disappointing that using the two extra dots for formatting or HTML effects hasn’t really caught on.
(As an example of how braille and screen readers handle HTML elements, we have links: a screen reader reads Lesswrong.com as “link Lesswrong dot com”, and on a braille display, it shows up as “lnk Lesswrong.com″. I consider the latter to be more problematic, in that it costs 4 whole cells, which is anywhere from 5% to 33% of the display!)
•One can tag friends and Facebook groups and pages, subject to some restrictions. For friends tagged, the anchor text can be shortened to any one word in their name.
Side complaint: Facebook accessibility is mixed, and blind people tend to use the mobile site, where in-line friend-tagging is not possible. (Yes, the main Facebook page is bad enough that this is more than a reasonable tradeoff.)
•Training users: The augmented text features need a loyal userbase that supports and implements them. So each augmentation needs to be introduced gradually in order to give users onboarding time.
This is so obviously applicable to anything accessibility-related that I momentarily considered not including it here.
•Performance in terms of speed and reliability: Each augmentation adds an extra layer of code, reducing the performance in terms of speed and reliability. As computers and software have gotten faster and more powerful, and the Internet companies’ revenue has increased (giving them more leeway to spend more for server space), investments in these have become more worthwhile.
Referring back to m.facebook.com Vs facebook.com: it’s very hard for accessibility technology, an extremely tiny market with little funding and lots of coordination problems due to size, to keep pace with all these augmentations. The more powerful stuff on Facebook.com gives me lag that ends in me queerying my brain for incidents in the early 2000s to try and find something comparable.
For another example: Lesswrong is usually pretty responsive to screen readers, but if a post has a large number of comments (I’ve noticed that 80 or more tends to be a good predicter), there might be enough lag in reading or loading to be inconvenient, and there is a particular feature that is actually annoying: occasionally, while reading comments, I’ll be notified of a comment’s percent positive karma, at which point the screen reader takes a whole second to get back to reading, adds more spoken formatting information (“clickable”, mostly; bold/italics/font size are almost never spoken, but screen readers are getting better about those), and once this happens once, it will almost definitely repeat if I keep scrolling. (My solution so far has been to switch to “just read everything from the cursor down” if this happens. How more or less convenient this method is depends on the screen reader. And I’m using the free one, because I’d rather not incentivize charging $800 for a screen reader.)
However, when I’ve tried using a braille display and text-to-speech simultaneously, I’ve found that, frequently, a page that will take several seconds to get a response from TTS will start displaying braille much more quickly. Considering that the screen reader is managing both, this is a little bizarre; it’d imply that the lag is in the TTS program, rather than the screen reader itself, yet different screen readers seem to render speech faster or slower on the same websites.
(my reply wound up over 8kb long, but I don’t think it’s general enough to turn into a discussion article.)
Reading this and its comments immediately made me think of the current status of braille, where technology has completely failed to keep up with the mainstream, and now many people are claiming that braille is outdated and they’ll just use text-to-speech for everything. (Disclaimer: I was taught braille starting from kindergarten, and picked it up fast and thoroughly. A lot of anti-braille people appear to have had a very hard time learning it and can’t actually read any quicker than I could read large print when my vision was at its best. So I have to acknowledge some kinda privilege when talking about the subject. I’ll also acknowledge that mastery of braille and financial/academic/etc success are positively correlated among blind Americans, according to all the not-incredibly-transparent sources I’ve found.)
Some of the points made here about text in general apply to braille, some are just the opposite, and some depend entirely on the audio/video/tactual affinities of the specific user. For example:
Is one of the arguments I use in favor of braille whenever the subject comes up, and it’s easily extended to consumption: noise and reading, noise and writing, privacy, the need/lack for headphones, all the different environments in which one can work, etc.
This, though:
Is only technically true for braille, since braille technology is so far behind that devices are almost always bulky, expensive, cumbersome, in addition to the mainstream device to which they connect, and only the most expensive and bulkiest models display more than 40 characters at a time (so like half of one print line… and most people will get an even smaller model, because even 40 characters is bulky, expensive, and generally more than trivially inconvenient to use on anything but a dedicated device like the PACMate Omni). The base format, digitally, is the same and can be transmited and stored easily, but everyone who can hear but not see is going to convert it to speech anyway.
Applies to text-to-speech as well; most TTS has adjustable speaking rates, and it’s possible to go back and reread things (however, checking the spelling of words is a trivial inconvenience which almost no one that relies on a TTS ever uses. Ever seen me misspell something? That’ll be why. On the other hand, what types of errors count as obvious visually vs obvious audibly differ, so blind and sighted text speak tend to differ simply for readability’s sake.).
Even people who don’t care for braille in general will agree that it helps loads with math and programming for exactly this reason. If hooking a braille display to a laptop were not so bloody inconvenient (and did not require so much desk-space), I’d have one connected pretty much all the time for this alone.
People usually reply to this with “Use the Windows volume mixer.” (I disagree with said reply under most conditions. If I have to have music quieter than a screen reader, then a lot of the impact is reduced. And screenreader + conversation is just plain impractical.)
Depending on the device, the opposite can be true for braille; a small display, or something smaller than a novel (braille novels are enormous) can be read while walking without compromising one’s awareness of one’s surroundings (especially if one can read one-handed). Audio is dependant on the device as well, however; walking around with bulky headphones on is a terrible idea (compare texting while driving), but external speakers while going about other business in the same room is fine.
Braille does not do formatting well, but neither does audio, and I’ve never had access to a braille device that can actually perform the equivalent to clicking or tapping a hyperlink. This is an improvement I thought of the first time I actually had a braille display for more than 5 minutes: every braille display I’ve ever seen includes cursor-routing keys, which are basically buttons above each cell that will move the cursor to that position when clicked. The obvious thing to do is to double-click one of those to simulate a mouse-click at that spot, yet I’ve never heard of this being implemented.
There’s also such a thing as 8-dot braille, which is typically used for unicode characters, to indicate capitalization, or to indicate the position of the cursor or highlighted text. Even most braille-using techies don’t learn 8-dot unicode (and from what I can tell, that isn’t even standardized, so it’d only matter for the specific hardware/software combination that one studied with), so it’s a little disappointing that using the two extra dots for formatting or HTML effects hasn’t really caught on.
(As an example of how braille and screen readers handle HTML elements, we have links: a screen reader reads Lesswrong.com as “link Lesswrong dot com”, and on a braille display, it shows up as “lnk Lesswrong.com″. I consider the latter to be more problematic, in that it costs 4 whole cells, which is anywhere from 5% to 33% of the display!)
Side complaint: Facebook accessibility is mixed, and blind people tend to use the mobile site, where in-line friend-tagging is not possible. (Yes, the main Facebook page is bad enough that this is more than a reasonable tradeoff.)
This is so obviously applicable to anything accessibility-related that I momentarily considered not including it here.
Referring back to m.facebook.com Vs facebook.com: it’s very hard for accessibility technology, an extremely tiny market with little funding and lots of coordination problems due to size, to keep pace with all these augmentations. The more powerful stuff on Facebook.com gives me lag that ends in me queerying my brain for incidents in the early 2000s to try and find something comparable.
For another example: Lesswrong is usually pretty responsive to screen readers, but if a post has a large number of comments (I’ve noticed that 80 or more tends to be a good predicter), there might be enough lag in reading or loading to be inconvenient, and there is a particular feature that is actually annoying: occasionally, while reading comments, I’ll be notified of a comment’s percent positive karma, at which point the screen reader takes a whole second to get back to reading, adds more spoken formatting information (“clickable”, mostly; bold/italics/font size are almost never spoken, but screen readers are getting better about those), and once this happens once, it will almost definitely repeat if I keep scrolling. (My solution so far has been to switch to “just read everything from the cursor down” if this happens. How more or less convenient this method is depends on the screen reader. And I’m using the free one, because I’d rather not incentivize charging $800 for a screen reader.)
However, when I’ve tried using a braille display and text-to-speech simultaneously, I’ve found that, frequently, a page that will take several seconds to get a response from TTS will start displaying braille much more quickly. Considering that the screen reader is managing both, this is a little bizarre; it’d imply that the lag is in the TTS program, rather than the screen reader itself, yet different screen readers seem to render speech faster or slower on the same websites.
Thanks for commenting! This is an insightful perspective.