Teaching accessibility testing software in grades 9-10 (level 1) does not have to be complicated. Picture a UX researcher running a usability test with a screen reader user before a product ships. That kind of thinking is exactly what Oklahoma's grades 9-10 (level 1) computer science standard L1.IC.CU.02 asks students to practice \u2014 and it is very teachable with the right materials. This post walks through what the standard means, the misconceptions students bring to it, and discussion starters you can use tomorrow, whether you teach in a classroom or at your kitchen table.<\/p>\n
\nTest and refine computational artifacts to ensure access to a variety of user audiences.\n\u2014 Oklahoma Academic Standards for Computer Science (February 2023)<\/em><\/p>\n<\/blockquote>\n
In plain language: This standard asks Level 1 students (grades 9-10) to test a digital project for barriers that could exclude different users \u2014 including users with vision, hearing, or motor differences, users who speak a different language, and users with an older device or slow internet \u2014 and then improve the project based on what testing reveals.<\/p>\n
In student-friendly terms, the learning target is: "I can test a computational artifact for barriers affecting a variety of user audiences and refine the artifact to improve access based on what testing reveals."<\/strong><\/p>\n
What Students Should Be Able to Do<\/h2>\n
\n
- I can name at least four different user audiences an artifact should be tested for (vision, hearing, motor, language, cognitive, or device\/connection needs).<\/li>\n
- I can choose an appropriate testing method for a specific accessibility barrier and describe what it would reveal.<\/li>\n
- I can propose a refinement that directly addresses a barrier found through testing.<\/li>\n
- I can explain why testing again after a refinement is a necessary part of the process, not an optional extra step.<\/li>\n<\/ul>\n
Along the way, students pick up the working vocabulary of the topic: accessibility, usability, contrast, caption, keyboard, iteration, feedback, inclusive, cognitive, bandwidth, latency, navigation, audience.<\/p>\n
Accessibility Testing Software: Misconceptions to Watch For<\/h2>\n
These are the wrong turns students reliably take with this standard \u2014 knowing them ahead of time is half the lesson plan. Each correction strategy below comes straight from the unit's teacher guide (the paragraph and activity references point into the unit itself).<\/p>\n
1. "Accessibility only applies to users with a permanent physical disability."<\/strong><\/p>\n
Return to paragraph 7. Language, cognitive, bandwidth, and device barriers affect users with no disability at all \u2014 accessibility is about the widest possible range of user audiences, not one narrow group.<\/p>\n
2. "If an artifact works for the person who built it, it works for everyone."<\/strong><\/p>\n
Revisit paragraph 1. The design team usually shares similar abilities, language, and hardware, which makes them the worst-positioned group to notice barriers unlike their own experience \u2014 testing with real, different audiences is the only way to find those gaps.<\/p>\n
3. "Auto-generated captions or AI-generated image descriptions are always accurate and finished."<\/strong><\/p>\n
Point back to paragraph 4 and the Emerging Technology connection. AI-assisted accessibility tools are a useful starting point but require human review \u2014 an uncorrected error can actively confuse the user it was meant to help.<\/p>\n
4. "Fixing one accessibility barrier is the end of the process."<\/strong><\/p>\n
Emphasize the cycle in paragraph 8: test, refine, and retest. A single fix without retesting can fail in practice even when it looks correct on paper.<\/p>\n
Discussion Starters You Can Use Tomorrow<\/h2>\n
\n
- Think of an app or website you use daily. If you tested it with the sound off or using only a keyboard, what do you think would break first?<\/li>\n
- Why might a team that only tests an artifact with people similar to themselves miss serious accessibility barriers?<\/li>\n
- Describe a situation where a refinement made for one user audience (such as captions) ended up helping a completely different audience as well.<\/li>\n<\/ul>\n
Bringing It Home<\/h2>\n
This topic is a natural one for families. One ten-minute activity to try: Together, pick an app or website your family uses and try one accessibility test as a family \u2014 mute the sound and watch a video, or try navigating a page using only the Tab key on a keyboard. Ask your student what they noticed and what they would change. There are no wrong answers \u2014 the goal is hearing their reasoning.<\/p>\n
Where This Leads<\/h2>\n
Students who can test a computational artifact for barriers affecting a variety of user audiences and refine the artifact to improve access based on what testing reveals are building skills used every day in UX and accessibility research, web and front-end development, QA and test engineering, and localization.<\/p>\n\n
See the Unit in Action<\/h2>\n\n