UEFI BIOS Accessibility for the Visually Impaired

12/07/2017 ∙ by Rafael R. Machado, et al. ∙ UFSCar 0

People with some kind of disability face a high level of difficulty for everyday tasks because, in many cases, accessibility was not considered necessary when the task or process was designed. An example of this scenario is a computer's BIOS configuration screens, which do not consider the specific needs, such as screen readers, of visually impaired people. This paper proposes the idea that it is possible to make the pre-operating system environment accessible to visually impaired people. We report our work-in-progress in creating a screen reader prototype, accessing audio cards compatible with the High Definition Audio specification in systems running UEFI compliant firmware.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 2

page 3

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

The word inclusion has been widely used to denote the idea that all people are equal and, regardless of any special need, should have the same opportunities. In order to guarantee these rights to persons with disabilities, the United Nations Organization has created the Convention on the Rights of Persons with Disabilities [1]. This convention aims to make humanity stop seeing people with disabilities as incapable and worthy of charity, starting to treat them as members capable of having an active participation in society with rights and duties, as can be found in the foreword, items e) and n) of the convention [1]:

e) Recognizing that disability is an evolving concept and that disability results from the interaction between people with disabilities and barriers to attitudes and the environment that prevent their full and effective participation in society on an equal basis with other people.

n) Recognizing the importance for people with disabilities of their individual autonomy and independence, including the freedom to make their own choices.

This idea is strongly linked to the concept of accessibility, which aims to create the necessary ways for people, regardless of having some special need or not, to achieve a given task with the highest possible quality. In this context, the concept of universal usability has been created, with the objective of enabling more than 90% of people to use a certain technology without great difficulties [2, 3]. Examples of universal accessibility are accessible staircases, which provide easier access for wheelchair users but also can make the life of other users easier and more productive. For instance, accessible staircases can help someone pushing a baby stroller or an elderly person who has difficulties when climbing stairs. In short, everyone benefits when universal accessibility is taken into account. There are several places were the concept of universal usability can be applied, and one of them is software. With an increasingly connected world, it’s important to remember that people with all levels of education, knowledge and impairments are becoming users of software and deserve the attention of the software creators.

There is a growing number of information technology professionals who have some type of visual impairment. Among these professionals we can find programmers, network experts and a large number of professionals working with computer maintenance, among other specialties. In order to allow people with some type of visual impairment to perform computer related tasks, screen readers have been developed, which are software that aim to help the user navigate a visual interface through sound instructions [4]. For example, a user that is using a screen with three buttons could navigate between them through a pre-defined command (often the tab key), and with the help of the screen reader, listen the name of each button that is currently selected. One of the first software of this type was AccessDos in the 1990s, which was used to make the DOS operating system accessible [5].

Unfortunately, not all computer related tasks have tools that allow accessibility to all people. One example of vital software that completely lacks any accessibility support is the pre-operating system configuration screens (popularly known as BIOS). This is due to the fact that the pre-OS environment lacks a driver for the audio card, so it is not possible for a screen reader to run. Considering the previously mentioned fact that many visually impaired professionals work with computer maintenance, this can negatively impact the ability of a skilled but visually impaired user to perform simple tasks such as the configuration of a RAID card on a server, the setting of the real time clock or selecting the OS to be loaded on a dual boot system. These are examples of a myriad of tasks that can be done quickly in a pre-OS environment, without the need for an OS on the system. However, these tasks can be performed only with the help of another person who is not visually impaired, thus not allowing total autonomy of the visual impaired user.

Research indicate that there are around 285 million people with some type of visual impairment in the world, of whom 39 million are blind [6], so the lack of accessibility in the pre-OS applications represents a clear discrimination against these people, because they are not free to use their computers in the same way as people who do not have these conditions. The companies responsible for the development of firmwares seem not to be interested in creating this kind of accessibility. After all, only a small part of the population is visually impaired, and of this set very few people are computer literate at a level that using a screen reader would make some sense in pre-OS environments. Unfortunately, companies do not realize that when an application becomes accessible, all of the extra expense required for its development is payed by a larger number of users interested on their product [7, 8].

This paper proposes the idea that it is possible to make the pre-OS environment accessible to visually impaired people. Our long term goal is the development of a screen reader prototype for pre-OS environments and here we report our work-in-progress toward that goal. In Section II we outline the architecture of the proposed propotype. The first step of the construction of this prototype is the development of an audio driver for pre-OS environment, thus allowing sound applications to be developed in firmware. Given the complexities between the various manufacturers of pre-OS environments and hardware, this work was developed with focus on the firmware that follows the Unified Extensible Firmware Interface (UEFI) specification [9]. In Section II-A we describe this specification in more detail and how we intend to enhance it with the creation of a suitable sound driver. For the same reasons of the selection of UEFI as a base standard, we decided to start with audio cards that follow the High Definition Audio (HDA) specification [10]. In Section II-B we describe the HDA specification and our efforts in creating a driver for this specification. We conclude in Section III by listing the missing steps to fully realize the creation of the proposed prototype.

I-a Related Work

Nowadays there are several tools focused on accessibility for the visually impaired. Among them, screen readers are used when the user has very little or no sight at all [4]. The function of this type of assistive application is to guide the visually impaired user by describing the visual interface he is operating, as well as all actions performed by him. This allows the users to accomplish all possible tasks within the environment, such as reading documents, accessing e-mails and any other type of activity. This includes advanced tasks such as software development and system configuration changes and maintenance.

To create a screen reader, several pieces of software must work together, such as the sound drivers, the graphical interface frameworks, the voice synthesizer, etc. [11]. Fig. 1 shows how some of these components interact, mostly mediated by the operating systems. Screen readers are available for many environments, encompassing most OSs in use today, as shown in Table I.

Fig. 1: Screen reader architecture
Operating System Screen Reader
Windows
JAWS [12]
myReader [13]
Microsoft Narrator [14]
NVDA [15]
Linux
SUSE-Blinux [16]
Orca [17]
Mac OS
Proloquo2Go [18]
Voice Over [19]
Android Talk Back [20]
TABLE I: Screen readers

These projects have the same target and, besides some usability changes, all provide the possibility for the user to have an understanding of the environment they are using through audio instructions. They also have options to speed up the software’s speak cadence, so the user does not expend too much time when listening the instructions. For a non-trained listener, a high-speed setup would never be understood, proving that the visual impaired users compensate any kind of deficiency with an increase on their listening capabilities.

From a technical point of view, all these screen readers have in common the fact that they rely on the services provided by an operating system. These services range from hooks to the graphical interface frameworks to the sound infrastructure, including sound card drivers, among many others. Unfortunately, there is no screen reader able to be executed at the pre-OS environment because of the limited services provided. This is somewhat surprising considering the sophistication of the current generation of UEFI firmware, where the user interacts with the system through a mouse-driven graphical user interface.

Ii Towards an Accessible BIOS

The addition of a screen reader can be considered a first step of what in future will be an accessible UEFI BIOS, so visual impaired people can use the computers at all levels: operating system and pre-OS environment. From a user’s perspective the system should operate as shown in Fig. 2. After entering at the system’s BIOS, the user would be able to select each field at the screen, and when a given field receives the focus its content would be presented as a sound information, making possible for the user to navigate on the screen following the voice commands.

Fig. 2: Accessible BIOS

To achieve this objective we propose to integrate in the UEFI environment a sound infrastructure with a basic API tied to the UEFI graphics SDK, as shown in Fig. 3. With this foundation in place we can hook the screen elements of the SDK with sound output operations and create a screen reader tailored to the pre-SO environment.

Fig. 3: Screen Reader Architecture

In the remainder of this section we describe the current state of this research, focusing on the creation of a sound output infrastructure.

Ii-a Unified Extensible Firmware Interface (UEFI)

Since the 1960s, the firmware responsible for initializing the devices in a computer was written entirely in Assembly language. Over time, the equipment began to become increasingly complex, with the inclusion of new types of controllers and technologies. These firmware, which were no longer trivial software, started to become a tangle of lines of code in Assembly. To try to minimize this complexity a group of companies created the EFI (Extensible Firmware Interface) concept that later, after some changes, become the UEFI (Unified Extensible Firmware Interface) [9]. This standard defines the interfaces a firmware should export on a pre-OS environment and allows the creation of portable applications that run in this environment.

In addition to the UEFI specification, another very important specification for the evolution of computer firmware is the PI (Platform Initialization) specification, which defines the steps to be followed during the boot process, and the modules to be loaded at each step on equipment whose firmware is compliant with the specifications. The steps defined by the PI/UEFI specification are shown in Fig. 4. Each of the steps presented has a very specific function in the boot process, making this concept very modular and expandable. Table II shows the function of each step in the device’s boot process.

Fig. 4: PI/UEFI boot process [21]
Step Assignments
SEC
- Handle all system boot events
- Create a temporary location to be used as memory
- Ensure security requirements for the next step (root of trust)
- Pass important information to the next step
PEI
- Initiate permanent memory
- Perform memory division for specific function (memory map)
- Other firmware may be stored (option roms)
- Pass the control to the next step
DXE
- Produce Boot Services
- Produce Runtime Services
- Discover and run the DXE drivers in the correct order
BDS
- Implement platform boot policy (which device will start first)
TABLE II: Boot Phases

Note that the compatibility with the PI/UEFI specification is not restricted to notebooks and desktops. Any equipment may have firmware that follows this specification. One can find mobile phones, tablets and development kits that have firmware compatible with the specification, presenting only some necessary changes given cost and hardware restrictions. With this, portability between equipment and platforms becomes a much simpler task than it was used to be.

The DXE step is the time at which the drivers will be loaded during the initialization of a given system with firmware compliant with the PI specification, thus enabling components and peripherals to be started correctly. For example, in this step SATA controllers, PCI/PCI-e devices, video cards, among other numerous types of controllers and existing peripherals are initialized. In this work we propose to create a sound card driver for the UEFI environment, that will be loaded in the DXE phase. This driver will export a sound interface to all other applications running in the pre-OS environment.

Since most of the systems currently available already have an integrated sound card attached to the PCI-e bus, this driver would take advantage of the PCI-e protocols defined by the UEFI specification, making the complexity of such a driver much smaller. To further simplify the construction of the driver and increase its portability, we target HDA audio specification as we describe in the next section. We have created a proof of concept application to help in testing the driver being developed, since in the UEFI environment there is no difference between an application and a driver with respect to hardware access. The conversion of this conceptual application to a DXE driver would be straightforward.

Ii-B High Definition Audio (HDA)

Among various sound card architectures, a very popular one in the Intel High Definition Architecture (HDA). This specification defines a standard of communication to be followed by manufacturers who are interested in being compatible with existing Intel platforms. Among other things, this specification defines a communication interface to be adopted by the sound card manufacturers as well as the forms of interaction between the platform and the audio equipment. The specification includes the definition of the controller’s register set, the physical description of the interconnections, codec programming model, and architecture components of the codecs [10].

This architecture defines two types of devices, controllers and codecs. These two types of hardware work together in the system, enabling the playback of the desired audio. The best definition of these concepts come from the HDA specification [10]:

The High Definition Audio controller is a bus mastering I/O peripheral, which is attached to system memory via PCI or other typical PC peripheral attachment host interface. It contains one or more DMA engines, each of which can be set up to transfer a single audio “stream” to memory from the codec or from memory to the codec depending on the DMA type. The controller implements all the memory mapped registers that comprise the programming interface.

One or more codecs connect to the link. A codec extracts one or more audio streams from the time multiplexed link protocol and converts them to an output stream through one or more converters.

The verbs are the commands to be send to the codec, so the codec can be controlled and configured. The verbs are defined by the HDA specification, so a system with a HDA compatible audio needs to have a codec able to answer to all these commands. Examples of these commands are GetParameter (0xF00), Amplifier Gain Mute (0xB–, 0x3–) and Beep Generation Control (0xF0A, 0x70A). Most of the verbs have two ids, one to set the information and another one to retrieve it. All verbs can be found at page 216 of the HDA specification [10].

As concrete example, we have used for development a ASUSPRO P2540UA laptop [22]. This system has a High Definition Audio 1.0a compatible codec, that provides all the sound functionality of the machine. In particular, the codec used to test the prototype was a CX20752 Low-Power High Definition Audio CODEC, from Conexant Inc. [23].

Ii-C Prototype Application

This first hurdle to the development of sound capabilities in the UEFI environment is that the UEFI specification has no provisions for a sound protocol. This way we had to start the development in the lower layers. In particular, we had to start with the PCI Express bus, that have a interface defined in page 638 of the UEFI specification [9], as shown in Fig. 5.

GUID
#define
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_GUID \
{0x2F707EBB,0x4A1A,0x11d4,0x9A,0x38,\
0x00,0x90,0x27,0x3F,0xC1,0x4D}
Fig. 5: PCI-e interface

Using this low level interface we had first to establish a way to communicate with the HDA controller. To do that, a parser of the PCI configuration space of the chipset was created. This parser was developed using the PCI protocols defined by the UEFI specification and all the bytes were parsed following the chipset specification [24]. The HDA controllers are always located at PCI 0:27:0 (this means bus 0, device 27, function 0). Fig. 6 shows sample code used to write 32 bit values to the controller registers.

EFI_STATUS WriteControllerRegister32 (
  PCI_HDA_REGION* PcieDeviceConfigSpace,
  UINT64 Offset, UINT32 Value) {

UINTN handleCount = 0;
EFI_STATUS Status = EFI_SUCCESS;
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL*
  rootBridgeProtocol = NULL;
EFI_HANDLE* detectedHandles = NULL;

//fix base addres, from device 00 27 00
//(hda controller)
UINT64 HdaControllerBar =
  (PcieDeviceConfigSpace->HDBARL
                          & 0xFFFFFFF0);

Status =
  gBS->LocateHandleBuffer(ByProtocol,
    &gEfiPciRootBridgeIoProtocolGuid,
    NULL, &handleCount,
    &detectedHandles);

if(!EFI_ERROR(Status)) {

 Status =
   gBS->OpenProtocol(detectedHandles[0],
    &gEfiPciRootBridgeIoProtocolGuid,
    (VOID**) &rootBridgeProtocol,
    gImageHandle,
    NULL,
    EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL);

 if(!EFI_ERROR(Status)) {

   Status =
       rootBridgeProtocol->Mem.Write(
         rootBridgeProtocol,
         EfiPciWidthUint32,
         HdaControllerBar + Offset,
         1,
         (VOID*) &Value);

   gBS->CloseProtocol(detectedHandles[0],
     &gEfiPciRootBridgeIoProtocolGuid,
     gImageHandle,
     NULL);
  }
 }
return Status;
}
Fig. 6: WriteControllerRegister32

Once the communication with the HDA controller is set up, we were able to access the codec itself. To send commands to the codec the HDA specification defines some registers that are not mandatory, but that were present and operational on the system used for development. These registers are named Immediate Command Output Interface (ICOI), Immediate Response Input Interface (ICII) and Immediate Command Status (ICIS). To send a command to the codec the software must write the verb on the ICOI register, and check the ICIS register to detect when the command was processed. The result of the command will be placed in the ICII register. To execute these commands, the function WriteControllerRegister32 (Fig. 6) is executed receiving as parameter the offset of the ICOI, ICII and ICIS registers, according to the PCI-e configuration space of the HDA controller.

To validade correct communication with the codec we used two simple verbs: GetParameter (0xF00) and Beep Generator Control (0xF0A, 0x70A). The GetParameter verb is used to get the details of each widget present in the codec. We were able to validate the results after sending this verb to specific nodes in the codec comparing the result with the chipset datasheet. For example, the node 0 at the codec should return the information contained in Table III when the GetParameter verb is send to it, and we were able to observe exactly these values at the pre-OS environment with the prototype application.

Description Verb ID Parameter Response Comments
Vendor ID F00h 00h 14F1510Fh CX20452
Revision ID F00h 02h 0x00100100 Revision B0.
TABLE III: Node 0 Responses

The other verb tested used a node in the codec that has a very simple and well defined behavior. Fig. 7 shows a block diagram representing the codec’s nodes, including one named Beep Generator, at position 0x12, that allows the generation of audible beeps. We have sent the verb Beep Generator Control to this node, along with appropriate frequencies to be processed, and as a result beeps were heard as expected. This way we were able to validate the feasibility of accessing the sound card hardware in the pre-OS environment.

Fig. 7: Beep Generator

Iii Conclusion

In this paper we proposed the idea that it is possible to make the pre-operating system environment accessible to visually impaired people, and reported our work-in-progress in creating a screen reader prototype for UEFI BIOS with HDA sound cards. We have shown that the sound cards are accessible at the pre-OS environment, and that the development of a screen reader solution for such an environment is possible.

As we reported only a work-in-progress, many questions remain toward our goal of creating a working screen reader prototype. For example, how to handle DMA, and the fact that the PI/UEFI is executed on a single thread. Moreover, work will be needed to convert the developed code in a UEFI DXE driver, develop a graphic interface tool kit for the UEFI environment, having accessibility tags to be executed on focus events, and after that a screen reader. However, the hardest part would probably be to make the BIOS manufacturers recognize that visual impaired people should be remembered. The technical part, as shown, seems to be totally achievable.

References

  • [1] A. Hendricks, “UN convention on the rights of persons with disabilities,” Eur. J. Health L., vol. 14, p. 273, 2007.
  • [2] G. Meiselwitz, B. Wentz, and J. Lazar, “Universal usability: Past, present, and future,” Human–Computer Interaction, vol. 3, no. 4, pp. 213–333, 2009.
  • [3] B. Shneiderman, “Universal usability,” Communications of the ACM, vol. 43, no. 5, pp. 84–91, 2000.
  • [4] S. Allen, D. Songco, P. Plexico, and R. Morford, “A voice output module developed for a blind programmer,” JOURNAL OF VISUAL IMPAIRMENT & BLINDNESS, vol. 75, no. 4, pp. 157–161, 1981.
  • [5] G. C. Vanderheiden, “Ubiquitous accessibility, common technology core, and micro assistive technology: Commentary on “computers and people with disabilities”,” ACM Transactions on Accessible Computing (TACCESS), vol. 1, no. 2, p. 10, 2008.
  • [6] W. H. Organization. (2014, August) Visual impairment and blindness. [Online]. Available: http://www.who.int/mediacentre/factsheets/fs282/en/
  • [7] P. Sherman, “Cost-justifying accessibility,” 2001, accessed: 01-05-2016. [Online]. Available: https://goo.gl/B1PxRK
  • [8] W3C. (2015, October) Case study of accessibility benefits: Legal & general group (l&g). W3C. [Online]. Available: http://www.w3.org/WAI/bcase/legal-and-general-case-study
  • [9] U. Forum, Unified Extensible Firmware Interface Specification, UEFI Forum Std. 2.4, Rev. B, April 2014.
  • [10] I. Corporation, High Definition Audio Specification, Intel Corporation Std. 1.0, Rev. a, Junho 2010, página 16.
  • [11] J. Bidarra, M. Seiji Oyamada et al., “Development of an interactive kiosk with screen amplifier for the elderly and those with low vision,” Journal of Research and Practice in Information Technology, vol. 45, no. 2, p. 117, 2013.
  • [12] F. Scientific, “Jaws screen reader,” July 2017, accessed: 2017-7-4. [Online]. Available: http://www.freedomscientific.com/Downloads/JAWS
  • [13] myReader, “Myreader screen reader,” July 2017, accessed: 2017-7-4. [Online]. Available: http://www.myreader.org/
  • [14] Narrator, “Narrator screen reader,” July 2017, accessed: 2017-7-4. [Online]. Available: https://www.microsoft.com/
  • [15] NVAccess, “Our story,” October 2015, accessed: 2015-09-13. [Online]. Available: http://www.nvaccess.org/about/our-story/
  • [16] Blinux, “Blinux screen reader,” July 2017, accessed: 2017-7-4. [Online]. Available: http://leb.net/blinux/
  • [17] Gnome, “Orca screen reader,” July 2017, accessed: 2017-7-4. [Online]. Available: https://help.gnome.org/users/orca/stable/
  • [18] A. Ware, “Proloquo2go screen reader,” July 2017, accessed: 2017-7-4. [Online]. Available: https://itunes.apple.com/br/app/proloquo2go-symbol-based-aac/id308368164?mt=8
  • [19] Apple, “Voiceover screen reader,” July 2017, accessed: 2017-7-4. [Online]. Available: https://www.apple.com/br/accessibility/mac/vision/
  • [20] G. Inc, “Talkback screen reader,” July 2017, accessed: 2017-7-4. [Online]. Available: https://goo.gl/7JbnG
  • [21] Z. V. R. M. M. Suresh, Beyond BIOS: Developing with the Unified Extensible Firmware Interface.   Intel Press, 2010, página 13.
  • [22] A. Pro, “Asus pro,” July 2017, accessed: 2017-7-7. [Online]. Available: https://www.asus.com/Commercial-Laptops/ASUSPRO-P2540UA/
  • [23] I. Conexant Systems. (2015, May) Cx20752 low-power high definition audio codec data sheet. [Online]. Available: http://conexant.com/wp-content/uploads/2016/10/CX20752_ds.pdf
  • [24] Programmer’s Reference Manual (PRM) For the Intel® 82801GB ICH7 and 82801GR ICH7R I/O Controller Hubs, Intel® Std., April 2005. [Online]. Available: http://www.intel.com/content/www/us/en/io/io-controller-hub-7-hd-audio-ac97-manual.html