JAWS also reads the “less than or equal to” symbol incorrectly. Jaws incorrectly says “five dash two” when it should say “five minus two,” even when using the HTML entity − (not a regular dash) to specify the minus symbol. JAWS reads the plus symbol correctly, but not the minus symbol.It says “five two seven” when it should say “five plus two equals seven,” making it hard - or impossible - to write basic math expressions. Similarly, NVDA ignores the plus and equals symbols.This means web developers can’t use an asterisk to denote a required field on a form, unless they supplement the asterisk with some other NVDA-friendly method. The NVDA screen reader, for instance, doesn’t read hardly any typographical symbols at all in its default configuration, making common symbols like asterisks and plus symbols essentially useless to NVDA users.But every screen reader has major flaws in reading some aspect of typographical symbols. Screen readers will pause at commas rather than say “comma,” and screen readers will say “don’t” rather than say “don apostrophe t.” Those are reasonable decisions. Screen reader manufacturers have understandably decided that most users don’t need to hear every comma, period, and apostrophe in a document. This is partly (but not entirely) by design. If you use HTML entities or other special characters, you’ll hear even less. If you type an HTML document using all the punctuation marks available on your keyboard and listen to a screen reader read the document in a web browser, you’ll hear only some of the punctuation and characters read aloud to you. The way screen readers treat punctuation is incredibly inconsistent from one screen reader to another, and there isn’t a single screen reader on the market that can reliably handle the full set of punctuation marks and typographical symbols that you might want to use. You Can’t Count on Screen Readers to Read Most Punctuation or Typographic Symbols Part 3 will focus on problems with pronunciation, including common content - like telephone numbers, dates, and abbreviations - as well as uncommon or new words, or words with more than one possible pronunciation.Part 2 will focus on the problems with inline semantic markup.Part 1 of this series focuses on the way screen readers read (or don’t read) punctuation and typographic symbols.It’s high time for screen reader programmers to fix these problems, and to get some consistency across brands of screen readers, because right now it’s kind of a mess… and I’m just talking about text, typographic symbols, and static HTML here: the things that screen readers are supposed to excel at reading. These are problems with the screen reader software itself. It’s not the user’s fault, and it’s usually not the web developer’s fault either. If a screen reader fails to read important text, the user will fail to understand it. Sometimes that’s OK, but sometimes that’s really bad. Unfortunately, screen readers don’t always read what’s on the screen. If there’s one thing a screen reader ought to do really well, it’s read what’s on the screen. That’s why they call them screen readers, right? You would think that screen reader software would have perfected the art of reading text by now, because that was the whole reason why screen readers were invented. Screen readers are designed to do one thing: read what’s on the screen. Why Don’t Screen Readers Always Read What’s on the Screen? Part 1: Punctuation and Typographic Symbols Inclusive Design Prevent issues before they start.End-to-end Testing Keep watch with DevOps & enforce policy.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |