Research questions
Use these questions to keep the study focused and to connect each chapter to evidence you can realistically collect.
- To what extent do the tested PWAs meet WCAG and ARIA accessibility requirements for PWA-specific and core interactive features across the prespecified testing environment?
- How do visually impaired student participants complete predefined educational task paths in the tested PWAs, and what common accessibility barriers prevent successful task completion?
- Do PWA installation and operating modes (installed vs. browser-based) produce differences in screen reader support for dynamic content and state retention?
- How well do screen readers announce dynamic status changes related to offline access, reconnection, and application updates in the tested PWAs?
Methodology and data plan
Suggested approach
This study uses a mixed-methods design combining technical accessibility audit and voluntary participant task testing. One to two PWAs will be selected for controlled evaluation, with three to five complete task paths prespecified before data collection. All testing parameters will be prespecified: exact screen reader version, browser version, operating system version, and test for both installed and browser-based modes. The technical audit will assess keyboard navigation, accessible names and roles, focus order and recovery, dynamic status announcements, installation behavior, offline and reconnection behavior, and state retention after updates aligned with WCAG and ARIA criteria. Automated accessibility scans will only be used to support initial issue discovery, not to establish conformance. Task testing will be conducted by blind or low-vision student participants, with all procedures approved by an institutional ethics review board prior to recruitment.
Data and sample
Quantitative data will be collected for prespecified outcome metrics: task completion rate, number of unrecovered errors, number of participant requests for external assistance, count of focus management defects, and count of dynamic announcement defects. Qualitative data will be collected via post-task participant ratings of subjective interface clarity. All research logs will be de-identified to protect participant confidentiality, with no personal identifiable information stored alongside task data. All technical audit findings will be mapped directly to tested WCAG and ARIA success criteria for transparent reporting.
Suggested thesis outline
Adapt the sequence to your institution’s format and the evidence available to you.
- 01
Background and Context
Introduce progressive web applications, their growing use in education, and the importance of accessibility for screen reader users who are visually impaired students.
- 02
Related Work
Review existing literature on PWA accessibility and screen reader support for modern web applications.
- 03
Study Design and Pre-Registration
Document prespecified testing parameters, selected PWAs, task paths, and evaluation metrics before data collection begins.
- 04
Technical Accessibility Audit
Conduct systematic WCAG and ARIA aligned audit of all pre-identified PWA features to document technical accessibility barriers.
- 05
Participant Task Testing
Recruit eligible participants, conduct approved task testing, collect quantitative and qualitative data on user experiences with the PWAs.
- 06
Planned Analysis and Reporting
Specify how technical audit observations and user task outcomes will be compared and reported without claiming broader accessibility or conformance.
- 07
Conclusion and Recommendations
Summarize identified barriers, outline limitations of the study, and provide recommendations for PWA developers to improve screen reader accessibility.
Proposed abstract
This proposed study will evaluate screen reader support in one or two selected educational progressive web applications within a prespecified technical environment. The design will combine a structured review informed by WCAG, WAI-ARIA, and WCAG-EM with task-based testing involving consenting blind or low-vision post-secondary students under institutional ethics approval. Three to five task paths will be examined across documented browser and installed modes, with attention to keyboard navigation, accessible names and roles, focus recovery, dynamic announcements, installation, offline behavior, reconnection, and state retention. The analysis will report task completion, unrecovered errors, assistance requests, technical observations, and participant clarity ratings. It will not treat automated scans as conformance evidence or generalize beyond the tested applications, tasks, participants, devices, and software versions. The intended contribution is a reproducible evaluation protocol and bounded evidence that developers and researchers can inspect and adapt.
Evidence and search directions
- Map all technical accessibility criteria to requirements defined in W3C Web Content Accessibility Guidelines (WCAG) 2.2
- Evaluate correct implementation of accessible semantics and roles using definitions from W3C Accessible Rich Internet Applications (WAI-ARIA) 1.2
- Structure the full evaluation process following the steps outlined in W3C Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0
- Assess PWA installation behavior against requirements defined in the W3C Web Application Manifest specification
- Evaluate offline and reconnection functionality relative to expected behavior defined in the W3C Service Workers specification