My name is Aaron Page. I am Allyant\u2019s Director of Accessibility, and I am blind. I was born with congenital glaucoma and lost my remaining functional vision 15 – 16 years ago. I want to start by stating that my experiences are my own, and they are affected by my disability, my past experiences, and the assistive technologies I use. <\/p>\n\n\n\n
My experience may not be the same as other blind \/ low-vision users, and will certainly be different from the experience persons with other disabilities, such as motor\/dexterity or cognitive disabilities, may have as they try to access the Web. <\/p>\n\n\n\n
When accessing the Web, I primarily do so using the following devices and assistive technologies: <\/p>\n\n\n\n
In this article, we\u2019ll talk about what it is like to access websites and applications using the first device I mentioned above \u2013 a desktop\/laptop computer running Windows and using the JAWS screen reader. <\/p>\n\n\n\n
For those who have never heard a screen reader in action, it can be an illuminating experience. <\/p>\n\n\n\n
Below is a paragraph of text from the Allyant website, and following that is a short clip of this text being read out by my screen reader. Keep in mind that this is how my screen reader sounds when browsing websites, reading emails, etc., but this is only 60-65% of the maximum speed supported by my screen reader. <\/p>\n\n\n\n
\u201cAt Allyant, we believe every organization\u2019s journey toward equitable access should be simple and seamless\u2014eliminating the worry, stress, and uncertainty often associated with accessibility. For this reason, we offer many accessibility services and software solutions, spanning print and digital document remediation services, document remediation software, and digital accessibility auditing.\u201d<\/em> <\/p>\n\n\n\n Screen Reader demo<\/a><\/p>\n\n\n\n On one hand, you could say the answer to this is easy \u2013 a site that doesn\u2019t conform to the Web Content Accessibility Guidelines. On the other hand, as a user, I have encountered my fair share of sites that might not be WCAG-conformant but were still perfectly usable to me as a user of screen-reading software. <\/p>\n\n\n\n The opposite can also be true \u2013 a site or web application may technically conform to WCAG but be so clunky\/non-intuitive as to be functionally unusable to me and other users of screen reading software. <\/p>\n\n\n\n Speaking just as a user going to a website and trying to access it, there are a few things that will cause me to give up on the site in relatively short order: <\/p>\n\n\n\n If I visit a site and encounter any of these, I usually just close the page and try to find a different site that can serve my needs. <\/p>\n\n\n\n Not having any of the above-mentioned issues is a good start. Ensuring your site is WCAG-conformant is always the best way to ensure your site is accessible for all, but as mentioned earlier, just because a site is not WCAG-conformant doesn\u2019t mean it is not usable or that it is inaccessible to me as a user of screen reading software. <\/p>\n\n\n\n A few things I look for that can give me a quick clue as to whether or not the site is accessible\/usable include: <\/p>\n\n\n\n Web applications have been gaining popularity in recent years and are slowly replacing traditional desktop-style applications. However, as a user of screen reading software, I have mixed experiences with web applications.<\/p>\n\n\n\n Since web applications are, by their nature, content you interact with from within a web browser, they typically have a higher baseline accessibility compared to desktop applications. I have encountered plenty of desktop applications where I could do nothing, read nothing, interact with nothing, and the application was essentially a blank void as far as my screen reader was concerned. <\/p>\n\n\n\n However, this doesn\u2019t tend to be the case with web applications \u2013 usually, there will be at least some content within the web application that will be perceivable to a screen reader user, even if that is just text. <\/p>\n\n\n\n As a user, the most challenging part with web applications is often learning how to interact with them, what keyboard shortcuts must be used, etc. <\/p>\n\n\n\n When navigating a web page, there are standard keyboard shortcuts provided by the screen reading software, for example, pressing H to move by headings, L to move to lists, and commands to read by paragraph, line, word, and so on. <\/p>\n\n\n\n However, when using a web application, the user has to largely disregard all of their screen reader-specific keyboard shortcuts and instead use shortcuts provided by and specifically for that application. <\/p>\n\n\n\n For example, to move to the next post on Twitter, you must press the K key; to move to new\/unread messages in Slack, you must press Alt+Shift+DownArrow; and to move between panels in Microsoft Teams, you must use Ctrl+F6. <\/p>\n\n\n\n Learning application-specific keyboard shortcuts can often be frustrating for a screen reader user. I have spent years learning how to operate my screen reader and all of its specific shortcuts, just to have to forget all that and learn the keyboard shortcuts to operate a single, specific application. <\/p>\n\n\n\n This is one reason why simply providing a keyboard shortcut may not be as good a solution as it may seem \u2013 how will users learn about the keyboard shortcuts, how will users keep track of the available keyboard shortcuts, do the keyboard shortcuts interfere with other shortcuts provided by the operating system or common screen readers, do you have the necessary markup to ensure keyboard shortcuts are properly passed from the screen reader to the browser and more. <\/p>\n\n\n\n Given all this, it is always preferable to go with simple designs using semantic HTML elements, where you can let the screen reader interact with content like a web page instead of forcing it to operate like a web application. <\/p>\n\n\n\n Modern screen readers are amazingly powerful tools, and they provide many features and functionality to help users navigate and interact with even the most inaccessible sites. Simply having accessibility conformance issues doesn\u2019t necessarily mean your site is inoperable or unusable, but the best and only real way to ensure WCAG conformance<\/a> and genuine usability is through\u00a0live user testing<\/a>\u00a0by users with disabilities who use these assistive technologies daily.\u00a0<\/p>\n\n\n\n This is even more true when dealing with web applications, as their complex and unique interactions require even more user testing to ensure the application is intuitive and operates as expected when used with a screen reader or other assistive technology. <\/p>\n\n\n\nWhat makes a website bad\/inaccessible? <\/h2>\n\n\n\n
\n
What makes a website good\/accessible? <\/h2>\n\n\n\n
\n
My experience of using Web Applications<\/h2>\n\n\n\n
Conclusion <\/h2>\n\n\n\n