Skip to main content
Accessibility.com, LLC
Category: Assistive Technologies

JAWS

Also known as: JAWS, Job Access With Speech
Simply put

JAWS (Job Access With Speech) is a screen reader, a type of software that reads aloud the content displayed on a computer screen and lets people operate the computer using the keyboard. It is used primarily by people who are blind or have low vision to access websites, documents, and applications. JAWS runs on the Windows operating system.

Formal definition

JAWS (Job Access With Speech) is a Windows-based screen reader developed by Freedom Scientific. It converts on-screen content into synthesized speech output and can also drive a refreshable braille display, enabling non-visual and keyboard-driven interaction with the operating system, web browsers, and applications. JAWS interprets application and document structure, exposing user interface elements, text, and semantic information to the user; on the web it relies on accessible markup and accessibility APIs (for example, information conveyed through HTML semantics and ARIA) to render an intelligible experience. Because of its widespread use, JAWS is commonly employed in manual and assistive-technology testing to evaluate how content behaves in practice, complementing automated checks, which detect only a portion of accessibility issues. Note that behavior can vary across JAWS versions, browsers, and applications, so results should be validated in the target environment. This entry is informational and not legal advice; procurement and conformance obligations (for example, under Section 508 for U.S. federal contexts, or WCAG-referenced benchmarks cited in various ADA settlements and guidance) depend on jurisdiction and evolving regulation and should be confirmed with qualified counsel.

Why it matters

JAWS is one of the most widely used screen readers among people who are blind or have low vision, making it a practical benchmark for whether digital content works for non-visual users. When websites, documents, and applications expose accessible markup and semantic information correctly, JAWS can convey that content as synthesized speech or braille; when they do not, users may encounter unlabeled controls, unreadable content, or navigation that breaks down. For organizations working toward accessibility, how content behaves in JAWS is often a meaningful indicator of real-world usability rather than a purely theoretical one.

Because automated accessibility checks detect only a portion of potential issues, testing with an actual screen reader such as JAWS is commonly part of manual and assistive-technology evaluation. This helps teams identify problems that automated tools may miss, such as confusing reading order, inadequately described interactive elements, or dynamic updates that are not announced. Meeting technical success criteria or passing automated scans does not by itself guarantee an accessible experience for all users, and hands-on testing with tools like JAWS helps close that gap.

JAWS is also relevant in procurement and compliance contexts. In U.S. federal settings, Section 508 obligations may bear on assistive-technology compatibility, and WCAG-referenced benchmarks are frequently cited in various ADA settlements and agency guidance. These obligations depend on jurisdiction and evolving regulation, and this entry is informational rather than legal advice; organizations should confirm specific requirements with qualified counsel.

Who it's relevant to

People who are blind or have low vision
JAWS is used primarily by people who are blind or have low vision to access websites, documents, and applications non-visually, using the keyboard together with speech output or a refreshable braille display.
Accessibility engineers and QA testers
Because JAWS is widely used, it is commonly employed in manual and assistive-technology testing to evaluate how content behaves in practice. This complements automated checks, which detect only a portion of accessibility issues, and helps teams validate real-world usability across specific version, browser, and application combinations.
UX designers and developers
Designers and developers benefit from understanding how JAWS interprets structure and semantics, since screen reader output depends on accessible markup and accessibility APIs such as HTML semantics and ARIA. Testing with JAWS can reveal issues like unclear reading order or unlabeled controls that may not surface in visual review alone.
Compliance officers and procurement teams
Those responsible for accessibility conformance and procurement may consider JAWS compatibility when evaluating products, particularly in U.S. federal contexts where Section 508 obligations can apply. Requirements depend on jurisdiction and evolving regulation and should be confirmed with qualified counsel.
Legal counsel and business leaders
Counsel and decision-makers should be aware that WCAG-referenced benchmarks are frequently cited in ADA settlements and agency guidance, and that assistive technologies like JAWS are relevant to how accessibility is evaluated in practice. This information is not legal advice, and obligations evolve through regulation and case law.

Inside JAWS

JAWS (Job Access With Speech)
A screen reader for the Windows operating system developed by Freedom Scientific (part of Vispero). It converts on-screen content into synthesized speech and/or refreshable Braille output, enabling people who are blind or have low vision to operate a computer and navigate applications, documents, and web content.
Speech output
JAWS uses a text-to-speech engine to read interface elements, text, and status information aloud. Users can adjust voice, rate, and verbosity to suit their preferences and tasks.
Braille support
JAWS can send output to a connected refreshable Braille display, allowing users to read content tactilely as an alternative or supplement to speech.
Keyboard-driven navigation
Because many screen reader users do not use a mouse, JAWS provides extensive keyboard commands and shortcuts to move through headings, links, form fields, tables, and other structures.
Accessibility API reliance
JAWS interprets information exposed by the operating system and applications through accessibility interfaces (such as accessibility APIs and, in browsers, the accessibility tree). Content that correctly exposes names, roles, states, and values is generally conveyed more reliably.
Role in accessibility testing
JAWS is widely used by testers to evaluate how content behaves with a real assistive technology on Windows. Such manual testing complements automated checks and helps identify usability issues that automated tools generally cannot detect.
Relationship to standards and procurement
Screen reader compatibility is relevant to meeting Web Content Accessibility Guidelines (WCAG) success criteria concerning name, role, value, and keyboard operability. In the US, screen reader support is also commonly a consideration in Section 508 procurement for federal contexts. These standards are distinct from any single product.

Common questions

Answers to the questions practitioners most commonly ask about JAWS.

Does testing a website with JAWS guarantee that the site is accessible or legally compliant?
No. Testing with JAWS can reveal how a site behaves with one widely used screen reader, but it does not by itself guarantee accessibility or legal compliance. JAWS is a Windows screen reader, so results may differ from other assistive technologies such as NVDA, VoiceOver, or TalkBack. A page can perform reasonably in JAWS and still present barriers for users of other tools or in other browsers. Comprehensive evaluation generally combines automated checks, manual review against WCAG success criteria, and testing with multiple assistive technologies and real users. Meeting WCAG conformance or passing screen reader testing also does not, on its own, ensure immunity from legal claims; consult qualified legal counsel for compliance questions.
Is JAWS a free, browser-based tool like some other screen readers?
No. JAWS (Job Access With Speech), developed by Freedom Scientific, is a commercial screen reader for the Windows operating system and is typically obtained through a paid license, though license options and trial or home-use tiers may vary. It is distinct from free screen readers such as NVDA. JAWS is not a browser plug-in or an accessibility overlay; it is a standalone assistive technology that a blind or low-vision user runs on their own computer to interpret and interact with software and web content.
Which platforms and browsers does JAWS work with?
JAWS runs on the Windows operating system. It is commonly used with mainstream web browsers to navigate online content and with desktop applications. Because behavior can differ across browser and version combinations, testing teams often verify the specific pairings that reflect their target users. JAWS is not available for macOS, iOS, or Android; users on those platforms typically rely on other assistive technologies such as VoiceOver or TalkBack. Confirm current supported platform and browser combinations with Freedom Scientific's documentation, as support evolves across releases.
How should JAWS fit into an accessibility testing workflow?
JAWS is generally used as one component of a broader testing approach rather than a sole benchmark. A common practice is to run automated tooling first to surface programmatic issues, then perform manual keyboard and screen reader testing to evaluate the actual experience, since automated testing detects only a portion of accessibility issues. Testing with JAWS can help confirm that headings, landmarks, form labels, link text, and dynamic content are announced meaningfully. Where feasible, teams supplement JAWS testing with other assistive technologies and involve users who rely on screen readers day to day.
What accessibility issues can JAWS testing help surface?
Testing with JAWS can help reveal problems such as unlabeled or ambiguously labeled controls, missing or incorrect heading structure, non-descriptive link and button text, images lacking meaningful text alternatives, form fields without associated labels or error messaging, and dynamic updates that are not announced. Many of these map to WCAG success criteria that address name, role, and value; info and relationships; and status messages. Because a screen reader reflects how content is programmatically exposed, JAWS testing is often most useful when paired with manual review to interpret whether the announced experience is understandable and operable.
Why is JAWS relevant to Section 508 and procurement decisions?
In US federal contexts, Section 508 requires that covered information and communication technology be accessible to people with disabilities, and screen reader compatibility is a practical consideration in evaluating and procuring such technology. Because JAWS is a widely used screen reader among blind and low-vision users, organizations sometimes include JAWS compatibility as part of their evaluation of whether a product functions with assistive technology. Section 508 applies to federal agencies and covered federal contexts and is distinct from the ADA and other authorities; naming a specific screen reader is an implementation choice rather than a codified requirement. Requirements evolve through regulation and agency guidance, so consult current sources and qualified counsel for procurement decisions.

Common misconceptions

If a page works with JAWS, it is fully accessible and legally compliant.
Testing with JAWS validates the experience for one assistive technology on Windows, but other screen readers, platforms, and disability needs may behave differently. Conformance with WCAG and legal compliance depend on many factors, and no single tool guarantees either. Consult qualified legal counsel for compliance questions.
JAWS is a browser or a standalone accessibility fix that makes content accessible on its own.
JAWS is assistive technology used by the end user; it reads and conveys whatever the operating system and applications expose through accessibility interfaces. It does not repair inaccessible content. Poorly structured or improperly labeled content will generally still present barriers regardless of the screen reader used.
Automated accessibility checkers can substitute for testing with JAWS.
Automated tools detect only a portion of potential issues. Manual testing with a screen reader such as JAWS is generally needed to evaluate real interaction, reading order, and announcement behavior that automated checks cannot fully assess.

Best practices

Include JAWS in manual testing on Windows, but test alongside other screen readers and platforms rather than treating any one product as the definitive standard.
Verify that interactive elements expose correct name, role, state, and value, and confirm keyboard operability, since JAWS relies on this information to convey content accurately.
Test real user tasks and workflows with speech (and Braille where relevant), not just individual elements, to surface reading-order and announcement issues that automated tools generally miss.
Use current, supported versions of JAWS and browsers during testing, and document the exact software versions used so results are reproducible.
Treat screen reader testing as complementary to automated checks and to input from people who use JAWS regularly, rather than as a replacement for either.
For procurement or compliance decisions, such as Section 508 in US federal contexts or WCAG-based benchmarks, consult current agency guidance and qualified legal counsel, as requirements evolve through regulation and case law.