.png)
Every student relies on the course catalog to select classes, explore majors, and plan a path. For blind students using screen readers, the basic task often becomes difficult due to how the content is built behind the scenes.
I am Michael Taylor, a blind, screen reader user. Browsing course catalogs, degree requirements, and program bulletins is a common step when comparing schools. In practice, this experience is frequently flawed for screen reader users.
Where Course Catalogs Break for Screen Reader Users
Accessibility problems usually come from structure and labeling—not the subject matter.
-
Headings are missing or out of order. Without a logical heading structure, I am unable to jump between departments or sections using screen reader shortcuts.
-
Filter and sort controls are unlabeled or vague. Buttons with text like “Click here” provide no context.
-
Expandable sections do not announce the state. Accordions or disclosure widgets open visually but do not indicate whether they are “expanded” or “collapsed,” so navigation stalls.
Image-Only Catalogs and Untagged PDFs
A significant issue is improper digitization. Some institutions publish program bulletins and requirements as images or image-based PDFs. A screen reader cannot interpret text that is only present in a graphic.
What works:
-
Publish degree and program information as true HTML or properly tagged PDFs.
-
Do not embed critical information only in images.
-
Make links and file names descriptive.
When Tables Hide Information
Comparison tables (credits, required/elective courses, options for double majors or minors) can be long and complex. Without proper structure, navigation becomes unpredictable.
Typical failures
-
Focus moves in an illogical sequence (for example, down a column instead of across a row).
-
Row and column headers are missing or incorrect, so positioning and context are unclear.
What works
-
Use semantic table markup with
<th>for both row and column headers. -
Ensure a logical reading order and reliable keyboard navigation.
-
Expose position context so the screen reader can announce the proper headers with each cell.
Expand and Collapse Without Getting Stuck
Program menus often use expand/collapse to reduce visual clutter. If the control does not expose the state to assistive technology, newly revealed items may not be reachable.
What works
-
Use accessible disclosure patterns and expose state
-
Ensure all revealed items are keyboard reachable
-
Provide an announcement or focus management so users are aware of what has changed.
What Good Looks Like
When catalogs follow best practices, screen reader users can search, filter, and read course descriptions without needing to leave the keyboard.
-
Clear, semantic headings for departments, years, and course types
-
Well-labeled controls for filter, sort, and search
-
Keyboard-friendly filtering with visible, text feedback on changes
-
Accessible expanders that announce open/closed state
-
Readable content as HTML or tagged PDFs
Related guide: See Course Catalogs in the ADA Title II Compliance Guide for Higher Education for patterns and governance.
Why This Matters for Compliance and Inclusion
Under ADA Title II, public colleges and universities are required to ensure that their digital platforms are accessible. Course catalogs are part of that obligation. Accessibility is not a bonus feature; it is a requirement and a key factor in student success.
Compliance note: Public universities are subject to ADA Title II. Under the DOJ’s 2024 rule, large entities (population ≥ 50,000) must comply by April 24, 2026, and smaller entities by April 26, 2027, aligning catalogs and related pages to WCAG 2.1 Level AA. Building accessible catalogs now reduces risk and improves student success.
Fastest Way to Find Real Issues
Automated checks often miss dynamic filters, tables, and expand/collapse behavior. A combination of user testing and targeted fixes is needed.
Want expert help identifying catalog barriers?
Run a test with UsableNet AQA to find issues that impact real students.
Closing the Gap With Help
As a blind screen reader user, what actually helps is getting fixes into the product—not another report. The teams I see make real progress do a few simple things and repeat them:
-
Ship code that adds labels, structure, and keyboard paths
-
Check changes with assistive-technology users before release
-
Line up work with WCAG and Title II requirements
-
Keep testing as catalogs, filters, and vendors change
That is the model behind UsableNet Assistive—UsableNet's managed service for digital accessibility, which includes validation from people who use assistive technology, is mapped to WCAG and Title II, and is supported to ensure you stay compliant.
Related Resources
-
ADA Title II Compliance Guide for Higher Education — Patterns, governance, and checklists across the student journey.
-
Public Sector & Education Accessibility — Services for Title II readiness, WCAG-aligned testing, remediation, and training.
