Evaluate and improve website accessibility

[bryanwweber]

Abstract

Our website (source code in https://github.com/cantera/cantera-website) uses a modified Bootstrap-based theme. As best I can tell, Bootstrap includes some elements of web accessibility, but there is probably more we can do to improve. We should evaluate the current level of accessibility and see where improvements can be made.

References

https://www.macfound.org/pages/get-started/ is one place to get started, there are many more

[speth]

The linked reference is dead, but this seems to be the relevant content: https://www.macfound.org/about/how-we-work/diversity-equity-inclusion/inclusive-design/call-to-action

I guess at this point, any assessment should be focused on the upcoming revision to the website, that is, what's in the current development version docs at https://cantera.org/dev/ and the revisions in Cantera/cantera-website#263 that will be merged as part of the release of Cantera 3.1.0.

[speth]

I spent some time using the Lighthouse tool built into Chrome to evaluate potential accessibility concerns and address the ones I could (see Cantera/cantera#1753).

With the changes in that PR, Lighthouse now gives us a 100% score on its automated checks for all of the Sphinx-generated pages I tested, and 95-100% on the Doxygen-generated pages. The one issue it finds is with the lack of a title on the <iframe> elements that are used to contain things like class inheritance diagrams. This is an issue that's already been noted upstream.

In addition to the automated tests, I did some checking of the issues that Lighthouse notes for manual testing, such as checking that tab focus moves through the page in a logical order. One of my main takeaways from this exercise is that for many accessibility concerns, we are dependent on what Doxygen, Sphinx, the Pydata Sphinx theme, and Doxygen Awesome do. The good news is that all of them are doing reasonably well, and some of them are putting significant effort into improving accessibility.

The dependence on these other projects also means that we will need to periodically reassess accessibility when updating the versions of these dependencies that are used to build the documentation. I think the best way for us to manage this going forward will be to continue pinning these dependencies in our CI, and to review our accessibility status before each Cantera release. I've already added some notes to this effect to our "release howto" for developers. With that plan in place, I think we can close this issue once Cantera/cantera#1753 has been merged.