A scanned conference paper can look perfectly readable in a research archive while remaining inaccessible to a screen reader. Its text may be impossible to search or select, and its headings may offer no way to move through the document. Accessibility failures often show up in what readers can actually do, not in how a page looks. The first step is to check whether visitors can read, hear, operate, and understand the material.
Start with representative tasks
Choose a few tasks that matter on your site: find a paper through the navigation, read an article, examine a figure, download a PDF, and send a correction through a form. Try each using only a keyboard. Then repeat the checks with a screen reader and at a narrow viewport or high zoom level. Each can expose barriers the others miss.
For each problem, note the page, task, obstacle, and effect on the reader. An unlabeled search field can block access to an entire archive. Unnecessary narration for a decorative image is annoying, but usually less urgent. The Web Content Accessibility Guidelines (WCAG) provide a framework for evaluating barriers; they do not replace testing the tasks readers need to complete.
Make page structure meaningful
Use headings and landmarks to show relationships
Headings should describe the sections below them and follow a sensible hierarchy: an H1 for the page title, H2 for major sections, and H3 for subdivisions. If a heading looks too large, change its appearance with CSS rather than choosing a different level. Screen-reader users often scan by heading, and a label such as “More” tells them little.
Use semantic elements for navigation, main content, lists, tables, and buttons. Text styled to look like a button may not work from a keyboard or announce its purpose. Native HTML controls are a sound starting point; custom controls need their names, states, and keyboard behavior supplied separately.
Link text should make sense on its own. “Download the 2006 proceedings PDF” is more useful than “Download.” A visible table of contents can also help with long articles, provided its links work by keyboard as well as pointer.
Keep navigation and controls operable
Every interactive element needs a visible focus indicator. As someone presses Tab, they should be able to see which link, menu item, or field is active. Do not remove focus outlines with CSS unless you provide a clear replacement. Check that focus follows a logical reading order and does not vanish inside a menu or dialog.
A “Skip to main content” link lets keyboard users bypass repeated navigation. Menus should open and close predictably. A dialog should receive focus when it opens and return focus to its triggering control when it closes. Essential information must not appear only on hover; tooltips, expandable notes, and image controls need a keyboard-accessible route too.
Check motion separately. An automatically moving carousel can interrupt reading, while an animated demonstration may distract or cause discomfort. Let visitors pause nonessential motion and honor reduced-motion preferences. If a task depends on a timer, check whether users can extend it.
Write accessible text, images, and media
Describe what an image contributes
Alternative text should convey an image’s purpose in context, not inventory everything visible. A portrait in a biographical note may need the person’s name; a decorative border usually needs empty alternative text so it is skipped. For a plot of speech-recognition error rates, state the key finding in nearby text. A short alt attribute cannot carry every axis, data point, and qualification.
Historical material also calls for care with uncertainty. If a low-resolution figure does not show which method produced a curve, do not guess. A transcription or data table beside a complex chart may be more useful than a long, speculative caption.
Give prerecorded video accurate captions for speech and meaningful sounds. Provide transcripts for audio recordings, noting speaker changes when they matter. Transcripts make archival speech samples searchable and readable, but uncertain words should be marked rather than passing off a recognition system’s output as verified speech. When essential visual information is missing from the soundtrack, readers may also need audio description or an equivalent account.
Plain language need not flatten technical history. Define an abbreviation on first use and explain what a measure represents before interpreting its value. Break up dense passages, and distinguish a researcher’s original claim from a modern editorial explanation.
Check presentation under real reading conditions
Text and controls need to stand apart from their backgrounds. WCAG contrast guidance gives common minimum ratios of 4.5:1 for normal text and 3:1 for large text, with separate requirements for meaningful interface components. Check the actual colors used in hover, focus, disabled, and error states. Never rely on color alone to identify a result: red and green curves need labels or distinguishable patterns.
Enlarge the text and zoom to 200% and beyond. Watch for clipped labels, overlapping navigation, or horizontal scrolling that makes ordinary paragraphs hard to read. A desktop browser at high zoom can reveal problems that small-screen testing misses. Fixed-height containers are especially likely to cut off text when a visitor increases its size or spacing.
Give forms and downloads the same attention
Give every field a persistent label; placeholder text disappears when someone starts typing. Put instructions near the relevant control and explain required formats before submission. If validation fails, identify the field and say how to fix the problem. A red border is not enough. After submission, show a confirmation that does not depend on a brief visual flash.
Identify document formats in download links, and consider including file size when it affects downloading. A PDF is not accessible simply because its pages are legible on screen. For scans, check recognized text against the original, along with reading order, headings, table structure, document language, and figure descriptions. Errors in names or equations can change the historical record; where possible, keep the original page available alongside corrected text.
Start with heavily used files and pages, but be clear about work still in progress. If a document cannot yet be fixed, give readers a way to request an accessible version. Do not publish an automatically generated transcript or OCR layer without checking its accuracy.
Test changes as part of publishing
Automated checkers can flag missing labels, some contrast failures, and structural errors. They cannot tell whether alt text explains a diagram accurately or whether a form’s instructions make sense. Pair scans with keyboard and assistive-technology testing, and seek feedback from people who use the site in different ways.
Build those checks into publishing. Before releasing the next scanned paper, choose a paragraph containing names and technical notation. Search the PDF for a phrase from that paragraph, then listen to it through a screen reader. If the search fails or the passage reads incorrectly, fix the text layer before marking the document ready.