Skip to content

Instantly share code, notes, and snippets.

@mannyAndem
Last active March 24, 2024 05:58
Show Gist options
  • Save mannyAndem/0d102c82a4e4f3f55068358ba7989242 to your computer and use it in GitHub Desktop.
Save mannyAndem/0d102c82a4e4f3f55068358ba7989242 to your computer and use it in GitHub Desktop.
Testing the Ushahdidi Platform's Accessibilty

Testing the Ushahidi Platform's Accessibility

This short article describes the way I would go about testing the Ushahidi platform. I first go over the importance of making the web accessible for everyone, then, proceed to go over the accessibilty principles and guidelines outlined by WCAG. I conclude by outlining the way I would go about testing for these gudelines in the Ushahidi platform.

Why accessibility is important

Accessibilty is not about guidelines, it's about people. In the course of carrying out the research needed to write this article, I stumbled on an accessibility course 1 which I feel has profoundly changed the way I view and think about accessibility. Accessibility at it's core is about building the web in a way everyone can use, enjoy and contribute to. The guidelines are nothing more than a means to achieving this overall end goal. Accessibilty assures that all users, irrespective of their physical conditions, don't find our sites a pain to get through talk less of using. It is not about building sites those with disabilites can use, it's about building sites everyone can use :)

Accessibilty: essential for some, useful for all!

Back to the technical stuff

Going back to the technical stuff, we will first go over the WACG 2.2 principles and the guidelines under each as well as useful examples using the Ushahidi platform. WCAG 2.2 has four principles governing content on sites:

  1. Perceivable
  2. Operable
  3. Understandable
  4. Robust

Perceivable

The perceivable principle attempts to ensure that web content is presented to users in the way/format they can perceive it.

It has four guidelines:

  • Text alternatives are provided for non-text content. (especially for the images in the Ushahidi platform and the map).
  • For time-based media (video/audio/audio-visual content), alternatives are provided which serve the same purpose as the time-based media. (There isn't any time-based media in the platform so we won't need to worry about this).
  • Content is adaptable and can be programmatically presented in different ways. (The structure of the platform should be easily understood by ATs).
  • Content is distinguishable from each other and easy to see and perceive. (In the context of the Ushahidi platform, font-size should be adjustable by browwser settings or external stylesheets, there should be clear contrast between elements).

Operable

This principle focuses on the operability and navigability of sites and web apps.

It has five guidelines:

  • The site should be keyboard accessible. (Platform should be easily usable via keyboard, using inputs (as well as those post search controls shouldn't be a pain), purpose of elements should be clearly stated, especially for the sake of screen readers).
  • Users should be provided enough time to interact with content. (This does not really apply to the platform as there isn't a lot of time constrained content).
  • Content that may cause seizures or physical reactions is avoided. (Also doesn't apply to the platform)
  • Users should be able to easily navigate the site. (Site should be navigable by keyboard, things like skip links can be used to skip those navigation and search related blocks).
  • Users can interact with inputs via various media. (As ways of interacting with inputs on the platform don't require complicated gestures, this isn't a challenge)

Understandable

This principle focuses on making the content of sites and how it is operated easy to understand.

It has 3 guidelines:

  • Content should be readable. (Current language of the platform should be clear to ATs).
  • Site should be predictable. (Basically deals with consistency in the order of elements. In this regard, platform currently has a super consistent layout).
  • Site should provide input assistance. (Super important in relation to input validation in the platform. There should be a continuous feedback loop whenever an action is taken, whether successful or otherwise, e.g when creating collections, adding posts to collections, creating posts, updating settings etc.).

Robust

This principle focuses on making the content of sites robust enough to be interpreted and be compatible with a variety of user agents (browsers and ATs 2).

This principle has just one guideline:

  • Content should be compatible with present and future user agents. (Purpose of elements should be easily understood. Every button and input should have a purpose that's clearly spelt out)).

Having gone over the basic principles and guidelines of the WCAG, it's time to get to how I would test for them.

Testing the Ushahidi Platform

To test for level 2 WCAG adherence (AA standard), I plan to utilize a more manual approach to testing. As the Ushahidi platform isn't a mammoth site with hundreds of pages, a manual page by page testing of the entire site would not be impossible to implement. For each page, the A and AA success criteria for each guideline would be checked both manually and with the help of a cool tool I found while researching, Silktide 3.

To test a page, the typical process would go like this:

  1. Open the page to be tested in the browser.
  2. Use the silktide extension to carry out a preliminary test of the page. It would point out parts of the page with accessibilty problems.
  3. Manually test the page with different user personas. Using a screen reader (silktide comes with a screen reader), navigating the page with just the keyboard, etc.
  4. Check through the code of the individual components that make up the page to identify any other issues that might have been missed whlie testing in-browser.
  5. Document findings.

When testing is complete, the findings would be compiled into a WCAG-EM report 4. The report would then serve as a basis for improvements to the platform's accessibility.

Conclusion

Writing on this was extremely enjoyable as I got to take a more in depth look at the WCAG as well as learn a lot more about accessibility as a topic in general. Keeping the web open and inclusive for everyone should be a core consideration for all of us building and innovating on the modern web.

Thanks for reading to the end :)

Footnotes

  1. Awesome course by the way, you can check it out here

  2. AT: Assistive Technology

  3. Silktide is a browser extension that helps check for accessibilty issues in sites.

  4. More on WACG-EM:https://www.w3.org/TR/WCAG-EM/

@Erioldoesdesign
Copy link

This is a great document - the only feedback I have is eventually adding some examples from the Ushahidi platform to the Perceivable,
Operable, Understandable, Robust headings would be really great as best practice examples for others to follow 😄

@mannyAndem
Copy link
Author

Thanks for the feedback @Erioldoesdesign :)

Will add examples from the platform as you've suggested!

@mannyAndem
Copy link
Author

Hey @Erioldoesdesign, added examples from the Ushahidi platform as you suggested :)

@Erioldoesdesign
Copy link

@mannyAndem I see the additions in the brackets ( )

Great work! I'm really happy to see your thoughtful and clear examples 😄

@mannyAndem
Copy link
Author

Thank you for the feedback @Erioldoesdesign !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment