Accessibility testing: How we’re making OpenMRS more inclusive, step by step

Recently, we had the privilege of conducting a comprehensive Accessibility Audit for the OpenMRS community. We were encouraged by the community’s positive response and commitment to addressing the findings. Building on that momentum, SolDevelo is excited to share details about the first phase of accessibility testing and the improvements we have implemented within OpenMRS. This post outlines our pragmatic, cost-effective approach, focusing on “quick wins” identified in the audit that deliver significant value with minimal risk.

OpenMRS

OpenMRS (Open Medical Record System) is an open-source platform designed for managing electronic medical records (EMRs) in healthcare settings, particularly in resource-limited environments. It offers a flexible and customizable framework that allows healthcare providers to efficiently capture, store, and retrieve patient information. With its modular architecture, OpenMRS supports various healthcare workflows and promotes interoperability with other health information systems, ultimately enhancing the quality of care delivered to patients.

Why accessibility matters for OpenMRS

Given OpenMRS’s critical role in diverse healthcare settings, ensuring its accessibility is not just a technical requirement but a fundamental aspect of its mission. Digital accessibility means designing and developing the platform so that people with disabilities can perceive, understand, navigate, and interact with it effectively. For OpenMRS, this translates to several key benefits:

  • Empowering all healthcare staff: In many regions where OpenMRS is deployed, healthcare workers may themselves have disabilities (visual, motor, auditory, cognitive). An accessible EMR ensures these dedicated professionals can use the essential tools of their trade without barriers, contributing their skills fully.
  • Improving usability for everyone: Accessibility features often lead to better design and usability for all users. Clear navigation structures, logical layouts, sufficient color contrast, and keyboard compatibility make the system easier and more efficient for everyone, including users with temporary limitations (like an injury) or situational ones (like working in bright sunlight).
  • Widening the contributor and user base: An accessible platform is more welcoming to potential contributors and implementers worldwide, including those who rely on assistive technologies. This broadens the talent pool supporting OpenMRS’s development and deployment.
  • Aligning with Global Health Equity: True health equity means ensuring that the tools designed to improve healthcare are themselves inclusive. Prioritizing accessibility reinforces OpenMRS’s commitment to serving all members of the communities it reaches.

SolDevelo’s approach: Strategic & cost-effective

With the comprehensive Accessibility Audit Report providing a clear roadmap, our immediate goal at SolDevelo was to contribute tangible improvements to OpenMRS quickly and efficiently. We adopted a strategic, cost-effective approach focused on addressing the “low-hanging fruit” – accessibility barriers identified in our report that could be fixed without requiring extensive code rewrites or introducing potential instability to the wider OpenMRS platform.

Collaborative planning and prioritization

Our process at SolDevelo involved several key steps:

  1. Leveraging the audit data: We meticulously reviewed the findings from our own audit, paying close attention to the severity ratings and the nature of the identified issues across different OpenMRS modules and pages.
  2. Collaborative prioritization with OpenMRS stakeholders: Following the audit, a dedicated prioritization meeting was held between us at SolDevelo and key OpenMRS stakeholders. During this crucial session, we collectively reviewed the audit findings and established priorities based on impact versus effort. This collaborative approach ensured we focused on issues flagged as significant barriers (e.g., elements completely unusable with a keyboard, missing critical information for screen readers) but which required relatively contained code changes that we could implement effectively as “quick wins.”
  3. Defining and minimizing risk: Based on these agreed-upon priorities, a core part of our strategy was to minimize the risk of introducing regressions or unintended side effects. To achieve this, we consciously decided not to tackle fixes in this initial phase that involved:
    1. Bumping Major Dependencies: Updating core libraries or packages can have wide-ranging impacts.
    2. Large-Scale Refactoring: We steered clear of changes requiring significant restructuring.
    3. Modifying Core UI Packages or Generic Components: Altering foundational elements was deferred.
    4. Complex Logic Changes: We focused on presentation and semantic fixes.

This strategic planning, done in partnership with the OpenMRS community, allowed us to define a clear scope for impactful yet safe initial contributions.

Our work in practice: Implementing quick wins

Guided by the prioritized list and our risk-mitigation strategy, our team at SolDevelo then focused on implementing the actual fixes. This involved addressing common accessibility issues within specific, targeted areas of the OpenMRS platform. Our work in this phase included:

  • Adding missing image descriptions: We added appropriate alt text to images that convey important information, ensuring users relying on screen readers don’t miss context.
  • Correcting illogical content structure: We adjusted heading levels (<h1> – <h6>) on certain pages to create a logical document outline, crucial for screen reader navigation and overall page comprehension.
  • Making forms more accessible: We added missing <label> elements and programmatically linked them to their corresponding form inputs (<input>, <select>, etc.) for better clarity and interaction via assistive technologies.
  • Clarifying link text: We updated generic link text like “Click Here” or “More” within specific modules to be more descriptive of their destination.
  • Improving keyboard focus indicators: We ensured that interactive elements had a visible focus outline when navigated using the keyboard, applying simple CSS adjustments where sufficient.
  • Addressing color contrast issues: Where feasible with simple CSS changes, we adjusted text and UI element colors to meet WCAG contrast ratio requirements, improving readability for users with low vision.
  • Applying specific ARIA fixes: We corrected straightforward issues we found with ARIA (Accessible Rich Internet Applications) attributes to improve interpretation by assistive technologies. This included adding necessary attributes like aria-label for unlabeled controls, aria-describedby to link descriptive text, and ensuring elements used appropriate role attributes according to their function.

Beyond the quick wins: Documenting deeper issues

Importantly, our work extended beyond implementing these low-risk fixes. For the accessibility issues identified in the audit that fell outside the “quick win” criteria (due to complexity, potential regression risk, or dependencies on core UI libraries), we at SolDevelo have gathered detailed documentation and insights.

This involved internal efforts such as:

  • In-depth analysis: Clearly articulating why certain patterns are problematic and the impact on users with disabilities.
  • Source code research: For issues rooted in underlying UI libraries or complex components, we delved into the relevant source code to pinpoint the origin of the problem.
  • Developing recommendations: Formulating specific suggestions for how these more complex issues could potentially be addressed in the future, including possible code strategies or necessary refactoring approaches.

We are planning to share these detailed findings and recommendations with the OpenMRS community in the coming weeks. This documentation aims to provide a clear understanding of the remaining challenges and will serve as a valuable resource for the community to plan future accessibility enhancements that may require more significant effort. While our focus for implementation was on cost-effective quick wins, we ensured that the knowledge gained about deeper issues was captured and prepared for community discussion.

The journey continues: Impact, future steps

Following our collaborative planning, SolDevelo implemented a targeted set of initial accessibility fixes within OpenMRS. This practical work addressed issues like:

  • missing image descriptions (alt text), 
  • improper heading structures, 
  • inaccessible forms (<label>), 
  • ambiguous links, 
  • poor focus visibility, 
  • contrast problems,
  • basic ARIA attribute errors (aria-label, aria-describedby, role).

These “quick wins” directly enhance usability in the addressed areas, improving navigation and clarity for users with diverse needs, including those using screen readers or keyboards, and those with low vision.

While implementing these fixes, we also analyzed and documented the more complex accessibility challenges identified in our audit that fell outside the “quick win” scope due to dependencies or potential regression risks. We plan to share these detailed findings and recommendations with the OpenMRS community in the coming weeks to help inform future development efforts. We recognize that achieving full accessibility is an ongoing journey requiring continuous attention and broader community effort for these deeper issues.

SolDevelo is proud to have contributed this first phase of improvements to the OpenMRS platform. We want to thank the OpenMRS community for the opportunity to collaborate on enhancing this vital healthcare tool.

Enhance your application’s accessibility with SolDevelo

Is ensuring your web application is accessible to all users a priority for your organization? The work described above – conducting a thorough accessibility audit, identifying high-impact fixes, and implementing them efficiently – is a core part of SolDevelo’s expertise.

We help organizations:

  • Identify accessibility barriers: Through comprehensive audits using automated tools and expert manual testing.
  • Prioritize actionable fixes: Focusing on cost-effective solutions and “quick wins” for immediate impact.
  • Implement robust solutions: Our development team can implement fixes directly or provide detailed guidance for your team.
  • Build accessibility into your workflow: We offer training and consulting to foster long-term accessibility practices.

If you’re interested in improving the accessibility and reach of your own software, we’d love to talk. Contact SolDevelo today to discuss how our accessibility services can benefit your project.

Author

Scroll to Top