In January 2015, a blind Microsoft Windows user posted a petition asking Microsoft to come up with a fully functional screen reader in Windows 10. This petition received a great deal of attention, with a number of Twitter users tweeting support or else providing link for the petition.
Although the idea of a fully integrated screen reader for Windows isn’t new, the timing of this particular petition is of interest. With Apple and Google leading the way in mobile dominance and with their respective screen readers, blind smartphone users are accustomed to having their smartphones talk out of the box after adjusting some settings. Also, with growing number of blind users using Mac OS X and with increased interest in talking Linux distributions, it isn’t surprising to find more and more blind computer users demanding Microsoft to do something with their own operating systems or else make Narrator more functional. Lastly, now that Microsoft is about to unveil consumer preview of Windows 10 and with changing landscape in Windows screen reader market, it is natural to see blind consumers asking Microsoft to take this opportunity to enhance Narrator or develop a more feature complete screen reader and ship it as part of Windows 10.
However, a screen reader that works out of the box isn’t the complete picture of a screen reader. A feature complete screen reader is expected to not only work with built-in applications, but also be ready to tackle today’s applications and their building blocks. Also, if the above petition is accepted and becomes a reality, it needs to allow power users to customize its behavior, something that cannot be done unless this extensibility is considered. Lastly, leaving out a crucial audience – app developers – will not get the above petition going forward, as third-party developers are also involved to make Windows what it is today and to enhance its user experience. Based on evidence from desktop and mobile operating systems and with my experience working with screen reader developers, the author would like to ask the petition writers and commenters to think about the following points.
First, a complete computer system is composed not only of hardware and operating systems, but also includes third-party apps. A functional screen reader should not only work with built-in applications such as OneDrive, File Explorer and others, but also with third-party applications such as media players, chat clients, office suites and others. This gets interesting when it comes to supporting Microsoft’s own products such as Office, Windows Live packages and any future apps (Cortana, for instance; Cortana is special in that it needs to coordinate with screen readers to receive voice queries and output just the needed messages). Thus an OS-specific screen reader that only supports built-in programs is, in my opinion, a half-baked pie – a crust without a filling.
Second, application development and usage is akin to completing a jigsaw puzzle. Not just the screen reader developer should support third-party apps, power users should be given opportunities to customize the screen reader’s behavior. Part of the reason for success of third-party screen readers for Windows is their extensive extensibility frameworks, such as scripting, reacting to various events and wide range of customization options. Without user customization facility such as scripting framework and integration with facilities such as power Shell, a screen reader – especially a built-in screen reader for an operating system – is a half-baked pie – a cold pie.
Lastly, screen reading is a collaborative process. Not only screen readers need to access information from built-in applications, they need to access information from third-party programs, and the key to this access is held by third-party app developers. If third-party app developers doesn’t take screen reading to account when designing their apps (especially with Windows Store apps and those using GUI frameworks such as WX and QT), it would make life of screen readers harder, especially for those who expect to use these apps with a built-in screen reader. In other words, without collaboration from third-party application developers (after all, developers of third-party screen readers are third-party developers as well), the above petition and its efforts could best be described as a half-baked pie – a crust, filling with no icing.
So what is the complete picture of a screen reader, especially that of a built-in screen reader for an operating system? It needs to support third-party apps just as good as built-in programs, it needs to allow customization from power users via various methods and third-party developers should be willing to take advantage of it. In my opinion, if the supposed built-in screen reader is considered an essential part of an operating system, then it should be open for usage not only by users, but also by developers so that app developers can utilized its functionality (API’s and frameworks provided by that screen reader, etc.), as without collaboration from outsiders, the effort would be best described as a half-baked pie, a half-baked solution and food in a picture. Not that I oppose this petition, but I think petition writers and commenters should also consider the petition’s impact on application programmers, as the idea being proposed – screen reading facility – is something that not only be used by users, but also can be used by developers to make their apps more accessible and appealing for blind and visually impaired Microsoft Windows users (application programmers hold the key to accessibility of their apps for screen reader users).
Thanks.
