There is an increasing recognition of the need to make education more accessible to students with diverse needs. The government of Ontario, for example, passed the Accessibility for Ontarians with Disabilities Act in 2005 [1]. Ontario’s universities have produced a set of guidelines to help instructors make their classes more accessible [2]. Recognizing this as a step in the right direction, we were inspired to make a tool that would give feedback to instructors about their lectures, allowing them to modify it to make sure their students’ needs are being met.

What it does

A for Accessibility records the audio of an educator’s lectures and analyzes it using Google’s powerful Speech-To-Text and Natural Language APIs. This analysis includes a whole bunch of important metrics carefully crafted by leading educators in order to help teachers understand the impact of their lectures on students of all types [3]. These metrics focus on tracking things like WPM [4,5], phrase complexity [6,7], and topic focus. Once the analysis is complete, the metrics are returned to the educator along with helpful tips explaining why tracking things like WPM is important, and how they can improve future lectures to make their content more accessible. In addition to this, a transcript of the lecture is returned, with questions highlighted to help the educator track common questions and address them more permanently through email or a Learning Management System.

How we built it

A for Accessibility is a full-stack application with the frontend made with Nuxt.js and Vuetify.js, and the backend made with Flask in Python. For our database we chose to use MongoDB Atlas. Our backend is enhanced with Google’s Speech-To-Text and Natural Language APIs to provide the analysis of audio that is passed back from the frontend, with all the computation being performed in Python. Our system was deployed through Google’s App Engine service.

Challenges we ran into

Constructing a full-stack application with so many moving parts is never easy. Our biggest challenge was making sure all the individual components of our application worked together properly. Another big challenge was choosing the most important indicators for accessible lectures. The solution to this problem was just extensive research! After a lot of work we were able to establish a common baseline for the most important indicators, and craft thresholds and tips to actively help educators to meet these baselines.

Accomplishments that we're proud of

We are very proud of our seamless end-to-end processing of audio. From recording audio on the frontend, we can pass that audio to the backend, store it, and run a variety of analysis on the audio and resultant transcript.

What we learned

We learned that there are many powerful tools made easily accessible to student developers that can aid in the development of projects.

What's next for A for Accessibility

We have addressed the aural component of accessible teaching but any lecture can be made accessible along other dimensions as well. In the future we intend to implement a video recording of the lecture. By using machine learning tools we will analyze the video and provide feedback to the lecturer about how often they were facing students, how much they moved around in class, as well as other metrics that correspond to an accessible teaching style.

Additionally, we plan on implementing a student facing service where they can submit written questions to the instructor during the lecture. The timing and topics of these questions would allow the lecturer to determine difficult areas in the lecture they need to revisit. This feature will be particularly helpful for larger classes where every student may not have the opportunity to ask questions.

Repetition of the core themes of a lecture and contextualizing concepts with examples are key features of more accessible teaching. We plan to implement more rigorous content analysis of the lecture to allow us to automatically detect when a lecturer repeats a theme from the lecture or provides an example.




[3] Centre for Teaching Excellence, University of Waterloo, "Lecturing Effectively in the University Classroom."

[4] Dale, Edgar, and Jeanne S. Chall. "A formula for predicting readability: Instructions."

[5] Carver, R. P. "Effect of increasing the rate of speech presentation upon comprehension." Journal of Educational Psychology. 1973. 65, p118-126.

[6] Flesch, R. F. "How to test readability."

[7] Foulke. E. & Sticht, T. G. "A review of research on time compressed speech." Psychological Bulletin, 1969, 72. p50-62

Share this project: