Accessibility standards
Accessibility standards for our digital properties
Paldorin Digital builds its public documentation to meet Section 508, the accessibility requirement that applies to federal digital content and, by extension, sets the bar we hold ourselves to everywhere.
The requirement shaped the design, not the reverse
Accessibility on this site isn't a separate project or a checklist applied at the end. It's why our pages run high contrast, why documents are split into short modules, and why the layout looks as plain as it does.
Contrast you can read anywhere
Dark type on a plain light surface holds up on cheap monitors, in bright rooms, and after a projector washes the screen out.
Short, modular documents
Every policy is broken into sections with stable headings, so keyboard and screen reader users can move straight to the part they need.
Nothing requires a mouse
No hover, no drag, no timed response stands between a reader and the text on this page.
Structure marked up as structure
Headings are headings, lists are lists, and bold is emphasis. Markup order matches what you see on screen.
Section 508
What Section 508 asks of us
Section 508 requires that digital content be usable by people with disabilities. In practice that means readable contrast, simplified structure, and content that works with assistive technology rather than around it.
Contrast
Text and background stay at strong contrast. Hierarchy comes from headings and spacing, never from fading secondary text.
Images
Every image carries alternative text that describes its function in the document, not its appearance.
Interaction
No interaction is required to read a page. Nothing here depends on a hover, a drag, or a timed response.
Those three decisions cover most of what a documentation site has to get right. The rest is discipline: keeping pages short, writing in plain language, and testing before anything goes live.
Section 508 applies directly to federal digital content. We treat it as the floor for every public page we publish, including the ones no federal reader will ever open.
Contrast by default
High contrast by default
Our standard is dark type on a light, plain background, with the same treatment for graphics and interface elements. This comes straight from federal documentation guidance and from Section 508 practice generally.
It has a practical side benefit: high-contrast documents stay readable on cheap monitors, in bright rooms, and after a projector washes them out. What we don't do is put secondary text at low contrast for visual hierarchy. Hierarchy comes from headings and spacing instead.
Modular content and short pages
Why pages stay short
Documents are broken into discrete modules and kept short enough to minimize scrolling or page turning. A reader can hold the whole thing in view.
Why headings stay stable
Splitting content into sections with stable headings helps screen reader users jump between regions, and helps sighted readers scan.
When a page grows
A long single-scroll policy page is hard to navigate with a keyboard and nearly impossible to cite precisely. When a module grows past its natural length, it becomes its own page.
Structure over styling
Headings are marked up as headings in document order, lists as lists, and tables only where a real comparison needs one. Bold text is used for emphasis, never to imitate a heading, because a bold paragraph gives a screen reader no navigation target.
Reading order in the markup matches visual order on screen. These are quiet rules. They surface the moment someone navigates by keyboard or listens to a page instead of looking at it.
- One heading level per region A screen reader can list every section without crossing a styling boundary.
- Tables only for real comparisons Column and row headers describe what they hold, so the data reads without the grid.
- Bold is emphasis, not a heading Emphasis gets no navigation target, so it never stands in for structure.
- Markup order equals visual order Tab and reading order follow the page, never jump around it.
Every interactive element is reachable and operable with a keyboard alone, and the focus indicator is always visible.
We don't remove focus outlines. Doing so makes a page unusable for the readers who depend on them most.
Skip links appear at the top of pages, so a keyboard user can bypass repeated navigation and land directly in the document content.
Keyboard and focus
We don't add keyboard traps or interactions that require a mouse gesture with no keyboard equivalent. If a control can be seen, it can be reached with Tab and activated with Enter or Space.
That rule runs through the documentation hub itself, not just the marketing pages. Opening a policy, switching between sections, and returning to the index all work without a pointing device — and without depending on a hover state to reveal the control in the first place.
Color, motion, and media
Color never carries meaning alone
Where color distinguishes something in a table or diagram, a label, pattern, or text marker carries the same information, so the distinction survives for anyone who can't separate the hues.
Nothing plays on its own
We avoid unnecessary animation, and we don't auto-play audio or video. Media plays only after a deliberate action, and captions and transcripts are provided for any recorded material we publish.
Alt text describes function
Images carry alt text that describes their function in the document, not their appearance. A reader who never sees the picture still gets what it was there to say.
Plain language as an accessibility feature
The writing standards in our Documentation Style Guide do accessibility work too. Clear sentence structure, one idea per sentence, and consistent terminology help readers with cognitive disabilities, readers using translation tools, and anyone reading in a second language or in a hurry.
Screen reader users also benefit from short paragraphs and descriptive link text. Plain language and accessible markup are the same effort seen from two angles, which is why both are mandatory rather than aspirational.
Testing before publication
Accessibility checks are part of the pre-publication review, not a follow-up task. Where we use automated tools, we treat their output as a floor: passing a scan doesn't mean the page works for a person.
- Step one Navigate with a keyboard Tab through the page and confirm every control is reachable, labeled, and visible when focused.
- Step two Check heading order Walk the outline from the top. Skipped levels and styled paragraphs standing in for headings get corrected before review ends.
- Step three Verify contrast Measure text against its background, including hover and focus states, and fix anything that slips below the bar.
- Step four Listen to the page Read key sections with a screen reader before the page goes live, and confirm the reading order matches the screen.
Issues found after publication are corrected through the same content governance process that handles any other document error.
Reporting a barrier
If something on this site blocks you from reading it, we want the specifics: page, section, the assistive technology or browser you used, and what happened.
That report goes to the document owner through the Contact page and is treated as an error, not a suggestion. We'd rather hear about a problem than have a reader give up quietly, and the fix often improves the page for everyone.
- Email:
- [email protected]
- Phone:
- +1 202-432-8110
- Hours:
- Monday to Friday, 9:00 AM – 6:00 PM Eastern Time
Questions readers send us
Which accessibility standard does this site follow?
Paldorin Digital builds its public documentation to Section 508. That standard drives our contrast, structure, and navigation choices.
Can I request a document in another format?
Yes. Use the Contact page, name the document, and describe the format you need. Requests route to the document owner.
Are images and diagrams described for screen readers?
Yes. Alt text describes the function of an image in the document. Where color or pattern carries meaning, a text label carries it too.
Does passing an automated scan mean the page is accessible?
No. We treat automated output as a floor and still navigate each page with a keyboard, check heading order, and listen to key sections with a screen reader before publishing.
If a page on this site gets in your way, tell us
Name the page, the section, and what happened. That report reaches the document owner and moves through the same review process as any other correction. Where the fix helps one reader, it usually helps the next one too.
Prefer to write? Reach the policy team at [email protected] or call +1 202-432-8110. Our office is at 1201 Wilson Boulevard, Suite 700, Arlington, VA 22209, and we answer Monday to Friday, 9:00 AM – 6:00 PM Eastern Time.