Accessibility

D&D Portal aims to make its rules, campaign information, character options, and reference material accessible to as many visitors as reasonably possible.

The website is designed with readability as a primary concern. Content should remain understandable and usable across different devices, screen sizes, input methods, and assistive technologies.

Accessibility is treated as an ongoing process rather than a one-time task. Pages, components, navigation systems, and visual styles may be updated when problems are discovered or better solutions become available.

Although the website aims to follow recognised accessibility practices, no claim is made that every page, feature, or third-party resource is completely free from accessibility barriers.

The main accessibility goals of D&D Portal are:

• Present information in a clear and predictable structure.
• Support navigation by keyboard.
• Use readable fonts and comfortable line spacing.
• Maintain sufficient contrast between text and backgrounds.
• Provide visible focus indicators for interactive elements.
• Use meaningful headings and semantic HTML.
• Provide text alternatives for meaningful images.
• Avoid unnecessary animation and visual movement.
• Support visitors who prefer reduced motion.
• Ensure layouts remain usable on smaller screens.
• Avoid relying on colour alone to communicate important information.
• Use clear labels for buttons, links, inputs, and navigation controls.

D&D Portal uses a font stack that prioritises legibility:

Atkinson Hyperlegible
Source Sans 3
Inter
System interface fonts

The typography is intended to provide:

• Clearly distinguishable letters and numbers.
• Readable paragraph widths.
• Comfortable line height.
• Visible heading hierarchy.
• Consistent spacing between sections.
• Reduced visual clutter around long rules text.

Visitors can also use their browser’s built-in zoom functionality to increase the size of text and interface elements.

Keyboard users should normally be able to:

• Move between links and controls using the Tab key.
• Move backwards using Shift and Tab.
• Activate buttons and links using Enter or Space where appropriate.
• Open and close navigation controls.
• Use search fields and filters.
• Identify the currently focused element.

Interactive elements use a visible focus outline based on the website’s accent colour.

:focus-visible {
        outline: 2px solid var(--accent);
        outline-offset: 3px;
}

The Wiki uses a collapsible sidebar for its main navigation.

On larger screens, the sidebar can be collapsed to provide more horizontal space for the page content. The collapse button should:

• Be reachable by keyboard.
• Have a clear accessible name.
• Indicate whether the sidebar is expanded or collapsed.
• Provide a visible focus state.
• Not trap keyboard focus.

On smaller screens, the navigation may open as an overlay. When the mobile navigation is open, it should be possible to close it without using a pointer device.

The background overlay should not be the only method available for closing the navigation.

Pages are intended to use semantic HTML and a logical heading order.

A typical page structure should contain:

1. One main page heading.
2. Second-level headings for major sections.
3. Third-level headings for subsections or cards.
4. Lists for related items or ordered instructions.
5. Tables only when information is genuinely tabular.

Headings should not be selected only because of their visual size. Their level should describe the structure and relationship of the content.

Page sections should also use descriptive titles so that visitors can quickly scan long rules pages or navigate through them using assistive technology.

Links and buttons serve different purposes and should be used accordingly.

Link text should describe its destination. Generic wording such as “click here” should be avoided when a more meaningful label can be provided.

External links may include a visual indicator, but their text should remain understandable without relying on the indicator alone.

D&D Portal uses a dark visual theme with light text and a bright green accent. The colour system is designed to maintain a clear separation between:

• Page backgrounds.
• Raised surfaces.
• Borders.
• Primary text.
• Secondary and muted text.
• Interactive and highlighted elements.

Campaign availability uses different colours for statuses such as allowed, limited, approval required, and banned.

Colour should not be the only way those statuses are communicated. Each status should also have a written label or another meaningful indicator.

Meaningful images should include alternative text that describes their purpose or subject.

Alternative text should normally:

• Describe the important information communicated by the image.
• Remain reasonably concise.
• Avoid repeating nearby visible text unnecessarily.
• Identify the character, class, creature, or location where relevant.
• Avoid phrases such as “image of” unless that wording adds meaning.

Purely decorative images should use an empty alternative text value so that screen readers can ignore them.

<img
	src="/classes/illrigger/card-female-l.webp"
	alt="Female Illrigger wearing dark infernal armour"
/>

<img
	src="/decorative-divider.svg"
	alt=""
/>

AI-generated images are also subject to these requirements. Their origin is documented separately on the AI Transparency page.

Tables are used for structured information such as class progression, level features, spell information, equipment values, and rule comparisons.

Tables should include:

• A clear heading or description.
• Proper table headers.
• Logical row and column relationships.
• Readable spacing.
• Horizontal scrolling on small screens where necessary.

Tables should not be used only to control visual layout.

When a table becomes difficult to use on smaller screens, the website may provide a scrollable container or a more suitable stacked presentation.

Search fields, filters, and other form controls should have visible or programmatically available labels.

Placeholder text should not be the only label for an input field because it can disappear once the visitor starts typing.

Form validation should:

• Explain what went wrong.
• Identify the affected field.
• Not rely only on colour.
• Preserve entered information where reasonably possible.
• Allow the visitor to correct the problem.

Search result counts and filter changes should be understandable to visitors using assistive technology.

D&D Portal aims to keep animation limited and functional.

The website respects the browser or operating system preference for reduced motion:

@media (prefers-reduced-motion: reduce) 
	html {
		scroll-behavior: auto;
	}

	.animated-element {
		transition: none;
		animation: none;
}

When reduced motion is enabled:

• Smooth scrolling should be disabled.
• Non-essential transitions should be removed.
• Hover movement should be reduced or removed.
• Important information should remain available without animation.

The website is intended to remain usable on desktop computers, laptops, tablets, and mobile phones.

Responsive behaviour may include:

• Changing multi-column layouts into a single column.
• Replacing the permanent sidebar with mobile navigation.
• Allowing tables to scroll horizontally.
• Increasing the available width for long text.
• Preventing buttons and links from becoming too small to operate.
• Keeping important controls within the visible page area.

Visitors should not be required to use a specific device orientation to access the main content.

D&D Portal aims to provide useful information to screen-reader users through:

• Semantic HTML elements.
• Descriptive headings.
• Accessible names for controls.
• Alternative text for images.
• Meaningful link labels.
• Correct list and table structures.
• Hidden text for context where visual icons are insufficient.
• Appropriate ARIA attributes where native HTML is not enough.

ARIA should not be used as a replacement for a suitable native HTML element. Where possible, native links, buttons, headings, lists, forms, and tables should be preferred.

Dynamic components should announce meaningful changes where the information would otherwise be unavailable to screen-reader users.

The website includes an .sr-only utility for text that should be available to assistive technology without being displayed visually.

.sr-only 
	position: absolute;
	width: 1px;
	height: 1px;
	padding: 0;
	margin: -1px;
	overflow: hidden;
	clip: rect(0, 0, 0, 0);
	white-space: nowrap;
	border: 0;

This may be used for:

• Additional labels for icon-only buttons.
• Context for external-link indicators.
• Descriptions of collapsed or expanded navigation.
• Status information not fully expressed by an icon.

Accessibility also includes the clarity of the written content.

Rule descriptions should aim to:

• Use clear and direct language.
• Explain uncommon terms.
• Separate rules from examples.
• Clearly label house rules and homebrew material.
• Identify campaign-specific restrictions.
• Break long information into meaningful sections.
• Use lists where they improve understanding.
• Avoid unnecessarily complicated sentence structures.

Simplifying wording should not change the intended meaning of an official rule. Where precision is important, the page should provide a source reference or link to the official wording.

D&D Portal is an actively developed project. Some parts of the website may still have known or undiscovered accessibility limitations.

Possible limitations may include:

• Older pages that do not yet follow the newest component structure.
• Images with incomplete or overly general alternative text.
• Tables that require horizontal scrolling on smaller screens.
• Third-party content that cannot be fully controlled.
• External websites with different accessibility standards.
• Experimental components that have not yet been fully tested.
• Colour combinations that may need further contrast review.
• Dynamic behaviour that may not yet announce every state change.

Known problems will be corrected where reasonably possible and prioritised based on their impact.

D&D Portal may link to or display content provided by third parties, including official Dungeons & Dragons websites, GitHub repositories, icon libraries, and other reference services.

The accessibility of those external services is controlled by their respective owners. D&D Portal cannot guarantee that an external website, document, embedded resource, or third-party tool meets the same accessibility goals as this website.

When a third-party resource creates a significant accessibility barrier, an alternative source or explanation may be added where reasonably possible.

Accessibility problems can be reported by email or through the public GitHub repository.

A useful report should include:

• The URL of the affected page.
• A description of the problem.
• What you were trying to do.
• The result you expected.
• The browser and device being used.
• The assistive technology being used, where relevant.
• Screenshots or recordings where they help explain the issue.
• A suggested improvement, where available.

If information on the website cannot be accessed because of an accessibility problem, contact toonvanberkel.public@gmail.com.

Please identify the page or information needed and describe the barrier. Where reasonably possible, the information can be provided in another accessible format or the page can be corrected.

Response times may vary because D&D Portal is independently maintained and is not operated by a dedicated support organisation.

Accessibility improvements may be introduced through:

• Manual keyboard testing.
• Screen-reader testing.
• Automated accessibility checks.
• Colour contrast reviews.
• Responsive-layout testing.
• User feedback.
• Code review.
• Updates to shared components.

Reusable components are preferred so that an accessibility improvement can be applied consistently across multiple pages.

Changes may be documented through the project repository and website changelog.

• About D&D Portal
• Credits
• Sources
• AI Transparency
• Privacy Notice
• Legal Notice