JAWS (Screen Reader)

JAWS, which stands for Job Access With Speech, is a screen reader application for Microsoft Windows developed by Freedom Scientific (a Vispero company). First released in 1995, JAWS has been the dominant commercial screen reader for decades and remains the most widely used screen reader among blind and visually impaired computer users worldwide, according to the WebAIM Screen Reader User Survey. A screen reader is software that interprets the content and structure of a user interface and presents it through non-visual means, primarily synthesized speech and refreshable braille displays. JAWS reads aloud the text on screen, announces interface elements like buttons and links, describes the structure of web pages through headings and landmarks, and provides keyboard commands that allow users to navigate and interact with applications without seeing the screen. JAWS works at the operating system level, intercepting information from the Windows accessibility API (MSAA, UIA, and IAccessible2) and from web browsers through the browser's accessibility tree. When a developer writes semantic HTML and proper ARIA attributes, JAWS can accurately convey that information to the user. When developers neglect accessibility, JAWS may present content that is confusing, incomplete, or entirely absent. JAWS supports a wide range of applications including web browsers, Microsoft Office, email clients, PDF readers, and many enterprise applications. It includes specialized features like a virtual cursor for web navigation, a forms mode for interacting with form fields, and scripting capabilities that allow customization for specific applications.

JAWS holds a significant position in the accessibility ecosystem for several reasons. **Market share.** According to WebAIM surveys, JAWS consistently ranks as the most used primary screen reader. This means that a large proportion of screen reader users will experience your website through JAWS. Ignoring JAWS testing means ignoring the screen reader most likely to be used by your audience. **Enterprise adoption.** JAWS has deep penetration in corporate and government environments. Many large employers provide JAWS licenses as their standard assistive technology offering. Employees who use JAWS to access internal applications and external websites expect those systems to work correctly with their screen reader. **Regulatory testing.** Section 508 compliance testing and many accessibility auditing standards reference JAWS as a primary testing tool. Federal agencies and their contractors are often expected to test with JAWS, making it a de facto standard in government accessibility. **Feature depth.** JAWS offers features that go beyond basic screen reading, including OCR for reading inaccessible images and PDF files, picture smart for AI-based image descriptions, customizable verbosity settings, and scripting for application-specific behavior. Its maturity and feature set make it a reference implementation for how screen readers should interact with web content. **Developer feedback.** Testing with JAWS reveals how well your HTML and ARIA implementation communicates to assistive technologies. Issues that JAWS exposes, such as missing labels, incorrect roles, or broken focus management, affect screen reader users broadly, not just JAWS users.

Understanding how JAWS interacts with web content helps developers build more accessible interfaces: **The accessibility tree.** When JAWS reads a web page, it does not parse the visual layout. Instead, it reads the accessibility tree, a structured representation of the page that the browser builds from the HTML DOM, CSS properties, and ARIA attributes. The accessibility tree contains information about each element's role (button, link, heading), name (the label or text content), state (expanded, disabled, checked), and relationships (what labels what, what describes what). **Virtual cursor mode.** When navigating web pages, JAWS uses a virtual cursor that moves through the accessibility tree sequentially. Users can press the down arrow to move to the next element, the up arrow to go back, H to jump to the next heading, T to jump to the next table, F to jump to the next form field, and many other single-key shortcuts. This navigation model is why heading structure, landmark regions, and proper element types are so important for screen reader accessibility. **Forms mode.** When a JAWS user encounters a form field and presses Enter, JAWS switches to forms mode. In this mode, keystrokes are passed directly to the web page rather than being intercepted as JAWS navigation commands. This allows users to type in text fields, select options, and interact with form controls. Proper labeling of form fields is critical because JAWS reads the label when the user tabs to a field. **Live regions.** When content on a page updates dynamically (such as a notification, status message, or updated search results), JAWS announces the change only if the content is in an ARIA live region. Without `aria-live` attributes, dynamic updates are silent, and screen reader users miss critical information. **Braille support.** JAWS supports refreshable braille displays, presenting text as tactile braille characters. Users who are deaf-blind or who prefer braille can read content through touch rather than speech. Proper semantic structure is important for braille users because braille displays have limited character width, and concise, well-structured content is easier to navigate. **Testing with JAWS.** To test a website with JAWS, launch JAWS and open the page in Chrome or Firefox. Navigate using the virtual cursor (arrow keys), check that all interactive elements have appropriate names and roles, verify that keyboard interactions work correctly in both virtual and forms mode, confirm that dynamic content changes are announced, and test that focus management behaves as expected when dialogs, menus, and other overlays are opened and closed.