The following policy concerns accessibility for page elements and styling on the EN SCP Wiki. It applies primarily as requirements to site-wide CSS themes and components, but much of it also applies to embedded CSS and custom formatting on individual pages. Users also have the option to create a separate "accessibility mode" version of their page as a method of meeting the policy.
See also the CSS Policy, which describes requirements for posted themes or embedded CSS on the site, and the Technical Content Policy. Note that all site styling and technical implementations are subject to modification at Technical Team discretion.
1) Perceivable
1.1 Text alternatives
1.1.1 (A): All informative non-text content (images, icons, diagrams) has an equivalent text alternative.
What this means: If an image/icon/diagram communicates information, people who can’t see it still need that information in words.
How to do it on Wikidot: Add alt text to important images. For icon-only links/buttons, make sure there is visible text or an accessible label in the component/theme.
Applying an alt in an image block:
[[include component:image-block name=SCP173.webp|caption=SCP-173.|alt=alt|alt-text=A statue facing the wall...]]
Applying an alt in a standard image:
[[image image-source.png alt="An image of ..."]]
Quick check: If you removed the image, would the page still make sense from the text alone?
1.1.2 (A): Decorative images are ignored by assistive tech (e.g., empty alt).
What this means: Decorative images shouldn’t be “read out loud” to screen reader users.
How to do it on Wikidot: Mark purely decorative images as decorative (empty alt) or use CSS background images for decoration. If you’re not sure, treat it as informative and describe it.
Quick check: Does the image add meaning, or is it just styling? If it’s just styling, it should be ignorable.
1.1.3 (A): Icon-only controls/links have accessible names that match purpose.
What this means: A magnifying glass icon must be announced as "Search", not "link" or "button".
How to do it on Wikidot: Prefer buttons/links with visible text. If you must use icon-only controls, ensure the component/theme includes a proper label.
Quick check: Would someone understand what the control does without seeing the icon?
1.2 Time-based media (if the page embeds videos or audio files)
1.2.1 (A): Audio-only pre-recorded has a transcript/equivalent alternative.
What this means: If there’s audio (podcast, recording), provide the words as text.
How to do it on Wikidot: Add a transcript below the embed/video.
Quick check: Could a Deaf user get the same information without playing audio?
1.2.2 (A): Video-only pre-recorded has a transcript/equivalent alternative or audio track.
What this means: If the video has important visuals but no useful audio, describe what happens.
How to do it on Wikidot: Provide a text description of the key visual information, or add narration in the video.
Quick check: If you couldn’t see the video, would you know what’s going on?
1.2.3 (A): Pre-recorded synchronized media has captions.
What this means: If there is speech (or important sounds), captions must be available.
How to do it on Wikidot: Use a player/source that supports captions, or provide an alternative with captions. If you can’t caption, provide a full transcript as a minimum.
Quick check: Turn sound off, can you still follow it?
1.2.4 (A): Pre-recorded video has audio description or media alternative.
What this means: If important visual events aren’t explained in the audio, provide a description (spoken or written).
How to do it on Wikidot: Add an audio-described version, or provide a “media alternative” (a structured text version describing the visuals + dialogue).
Quick check: Are there key visuals (text on screen, actions, scene changes) not mentioned in the audio?
1.2.5 (AA): Pre-recorded synchronized media has audio description.
What this means: For AA, provide audio description when visuals carry meaning beyond the soundtrack.
How to do it on Wikidot: Prefer an audio-described upload, or publish an accessible text alternative alongside the embed.
Quick check: Would a blind user miss important info because it’s only shown visually?
1.3 Adaptable
1.3.1 (A): Structure/relationships are programmatically determinable (headings, lists, labels, table markup for data).
What this means: Use real headings/lists/tables so assistive tech can navigate the page properly.
How to do it on Wikidot: Use Wikidot heading syntax ('++', '+++' etc.) instead of big bold text, use real bullet/number lists ('*' / '#').
Quick check: If a screen reader user jumps by headings or lists, will the page structure still make sense?
1.3.2 (A): Reading/order in the DOM is meaningful (sidebars, columns, modules don’t break order).
What this means: The page should make sense when read top-to-bottom (which is how many tools read it).
How to do it on Wikidot: Be careful with multi-column layouts, floated boxes, side content.
Quick check: Read the page without looking at layout, does the order still make sense?
1.3.3 (A): Instructions don’t rely only on sensory cues (colour/position/shape/sound).
What this means: Don’t say "click the red button on the right" as the only instruction.
How to do it on Wikidot: Refer to the control by name/label ("Select 'Edit'", “Use the 'Search' field") and include text cues, not just visual ones.
Quick check: Would the instruction still work if the user can’t see colour/position?
1.3.4 (AA): Content isn’t restricted to one orientation (portrait/landscape).
What this means: The page should work if someone rotates their phone/tablet.
How to do it on Wikidot: Avoid layouts that require a fixed width or force horizontal scrolling. Keep content responsive.
Quick check: Does the page still function in both portrait and landscape on mobile?
1.4 Distinguishable
1.4.1 (A): Colour is not the only way to convey information/state/action.
What this means: If colour indicates meaning (warning/safe/selected), there must also be text or another cue.
How to do it on Wikidot: Add text labels ("Warning"), icons with labels, patterns, or clear wording.
Quick check: If you removed colour, would users still understand?
1.4.2 (A): Any auto play audio > 3 seconds has pause/stop or independent volume control.
What this means: Surprise audio can block access for many users.
How to do it on Wikidot: Don’t autoplay. If a media embed autoplays, ensure controls exist immediately and are keyboard accessible.
Quick check: Load the page, does anything start playing without asking?
1.4.3 (AA): Text contrast meets APCA standard.
What this means: Text needs enough contrast against its background to read comfortably.
How to do it on Wikidot: Choose high-contrast colours for body text, links, and small text. Avoid low-contrast.
Quick check: Does it pass APCA contrast checker for your use case?
1.4.4 (AA): Text can be resized to 200% without loss of content/function.
What this means: People must be able to zoom in and still use the page.
How to do it on Wikidot: Avoid fixed-height containers that clip text. Avoid tiny font sizes. Test at 200% browser zoom.
Quick check: Zoom to 200%, does anything overlap, disappear, or become unusable?
1.4.5 (AA): Images of text are avoided when real text can be used.
What this means: Important words shouldn’t be baked into an image (screen readers can’t read them; zoom gets blurry).
How to do it on Wikidot: Use actual text + CSS styling instead of image headers. If you must use an image, repeat the text in the page content.
Quick check: Can the text be selected/copied? If not, it might be an image.
1.4.6 (AA): Reflow works at 320 CSS px width / 400% zoom without 2D scrolling (except true 2D content like large tables/maps).
What this means: On small screens or high zoom, users shouldn’t have to scroll left-right to read paragraphs.
How to do it on Wikidot: Avoid fixed-width boxes, wide images without scaling, and huge tables. For big tables, provide a summary or alternative view.
Quick check: At mobile width / 400% zoom, can you read paragraphs with only vertical scrolling?
1.4.7 (AA): Non-text contrast: UI components and meaningful graphics meet APCA standard.
What this means: Buttons, input borders, focus outlines, icons, and key graphics must be visible against their backgrounds.
How to do it on Wikidot: Ensure button borders/fields/focus rings are clearly visible; don’t rely on faint outlines.
Quick check: Can you clearly see input borders, buttons, and focus indicators? Do key graphics pass APCA contrast checker.
1.4.8 (AA): Text spacing overrides don’t cause loss of content/functionality.
What this means: Some users increase line spacing/letter spacing. The page must still work.
How to do it on Wikidot: Avoid containers that assume tight spacing (overlapping text, clipped popups). Don’t lock line heights.
Quick check: With increased spacing, does anything overlap, cut off, or become unusable?
1.4.9 (AA): Hover/focus-triggered popups (tooltips/footnotes/menus) are dismissible, hover able, and persistent.
What this means: If extra content appears on hover/focus, users must be able to keep it open, move into it, and dismiss it without losing their place.
How to do it on Wikidot: Don’t make hover-only info. Ensure popups also appear on keyboard focus, stay open when you move the pointer onto them, and can be dismissed (e.g., Esc or a close button).
Quick check: Can a keyboard-only user open the popup, read it, and close it?
2) Operable
2.1 Keyboard accessible
2.1.1 (A): All functionality is operable by keyboard.
What this means: Everything must work without a mouse (menus, rating, collapsibles, forms).
How to do it on Wikidot: Prefer standard links/buttons and known modules. Avoid custom scripts that only work on click/hover.
Quick check: Can you do everything using Tab, Enter, Space, and arrow keys?
2.1.2 (A): No keyboard traps (focus can always move away).
What this means: If you can tab into something, you must be able to tab out again.
How to do it on Wikidot: Be careful with modals, embedded media, and custom widgets. Provide a close button and Esc support where applicable.
Quick check: Does Tab ever get "stuck" in a widget?
2.1.3 (A): Single-character shortcuts can be turned off/remapped or only active on focus.
What this means: Pressing 'J' or 'K' shouldn’t unexpectedly trigger actions unless the user is in the right control.
How to do it on Wikidot: Avoid single-letter shortcuts. If they exist, only activate them when the relevant component is focused.
Quick check: Typing in a text field should never trigger page actions.
2.2 Seizures and physical reactions
2.2.1 (A): No content flashes more than 3 times per second (or stays below thresholds).
What this means: Fast flashing can trigger seizures or migraines.
How to do it on Wikidot: Avoid rapid flashing animations (especially 'glitch' effects). Keep animation subtle and slow.
Quick check: Nothing should rapidly flash or strobe.
2.3 Navigable
2.3.1 (A): Focus order preserves meaning and operability.
What this means: Tabbing should move through the page in a sensible order.
How to do it on Wikidot: Avoid layouts that cause focus to jump unpredictably (floating boxes, hidden menus, strange modules).
Quick check: Tab through, does it follow the content logically?
2.3.2 (A): Link purpose is clear from link text or context.
What this means: 'Click here' is unclear; links should say what they do.
How to do it on Wikidot: Write descriptive link text ("Incident Log", "SCP-173 File"). If repeating "Read more", add more context.
Quick check: Would the link still make sense if read out of context?
2.3.3 (AA): More than one way exists to find pages (search, tags, hubs/sitemaps, nav).
What this means: Users shouldn’t have to rely on only one method to locate content.
How to do it on Wikidot: Ensure search works, tags are used consistently, and hub pages provide navigation.
Quick check: Can you find the same content via search and via navigation/tags? Is standard site navigation maintained?
2.3.4 (AA): Headings and labels describe topic/purpose.
What this means: Section headings should match what the section is about.
How to do it on Wikidot: Use clear headings ("Containment Procedures", "Description") and label form fields clearly.
Quick check: Skim just the headings, do they outline the page accurately?
2.3.5 (AA): Focus is visible for all keyboard-operable UI.
What this means: Keyboard users must be able to see where they are on the page.
How to do it on Wikidot: Don’t remove focus outlines in CSS. Make sure focus is high-contrast and obvious.
Quick check: Press Tab, can you always see the highlighted item?
2.3.6 (AA, WCAG 2.2 new): Focus is not fully obscured by sticky headers/banners/overlays when focused.
What this means: When something gets focus, it shouldn’t be hidden behind a sticky header or popup.
How to do it on Wikidot: Adjust sticky header spacing, use scroll margins, and ensure popups don’t cover focused items.
Quick check: Tab to items near the top, do they disappear under a header?
2.4 Input modalities
2.4.1 (A): Label in name: accessible name contains the visible label text.
What this means: If a button says "Search", assistive tech should also announce "Search".
How to do it on Wikidot: Use visible text labels for controls whenever possible. Avoid icons-only or mismatched labels.
Quick check: The words you see should match the words announced.
2.4.2 (AA, WCAG 2.2 new): Target size minimum 24×24 CSS px (or spacing/exception rules are met).
What this means: Buttons/links must be big enough to tap easily on mobile.
How to do it on Wikidot: Avoid tiny icon links. Increase padding, spacing, or provide larger clickable areas.
Quick check: Can you reliably tap controls without zooming in?
3) Understandable
3.1 Readable
3.1.1 (A): Page language is set programmatically (lang).
What this means: Screen readers need to know what language to read in.
How to do it on Wikidot: This is usually a theme/site setting. Ensure the site/page language is configured correctly.
Quick check: Does a screen reader pronounce words correctly for the site language?
3.1.2 (AA): Language of parts is set where passages switch language.
What this means: If a paragraph switches to another language, assistive tech should be told so pronunciation changes appropriately.
How to do it on Wikidot: Avoid long unmarked foreign-language blocks; if used, clearly label the language and (if possible) use markup supported by the theme/components.
Quick check: Do foreign-language passages sound correct when read aloud?
3.2 Predictable
3.2.1 (A): Focus does not cause unexpected context changes.
What this means: Tabbing onto something shouldn’t suddenly open a new page or trigger an action.
How to do it on Wikidot: Avoid scripts that auto-open menus, popups, or navigation on focus without user action.
Quick check: When you Tab, nothing should "happen" except focus moving.
3.2.2 (A): Input does not cause unexpected context changes without warning.
What this means: Changing a dropdown shouldn’t instantly redirect unless the user is warned.
How to do it on Wikidot: Use explicit submit buttons and clear instructions.
Quick check: Changing a field should not unexpectedly move you away.
3.2.3 (AA): Navigation is consistent across pages.
What this means: Menus and navigation should appear in the same place/order across the site.
How to do it on Wikidot: Keep consistent theme/layout. Avoid page-by-page custom nav that changes location/order.
Quick check: Does the nav feel the same as other pages on the site?
3.2.4 (AA): Components with same function are identified consistently.
What this means: Don’t call the same action different things ("Submit" vs "Send" vs "Go") without reason.
How to do it on Wikidot: Standardize labels for common actions (Search, Edit, Save, Submit, Cancel).
Quick check: Are similar controls labelled the same across pages?
3.2.5 (A, WCAG 2.2 new): If help mechanisms exist, their placement/order is consistent across pages.
What this means: If there’s a help link/contact method, it should appear consistently so users can find it.
How to do it on Wikidot: Put help/contact links in the same nav/footer area site-wide.
Quick check: Can you find help in the same place on multiple pages?
3.3 Input assistance
3.3.1 (A): Errors are identified and described in text.
What this means: If something goes wrong, the page must explain what and where, in words.
How to do it on Wikidot: Ensure forms show clear text errors near the relevant field and at the top summary if possible.
Quick check: If you submit wrong data, do you get a clear message telling you what to fix?
3.3.2 (A): Labels/instructions are provided for user input.
What this means: People need to know what each field is for and what format is expected.
How to do it on Wikidot: Use visible labels, not placeholder-only hints. Provide examples ("DD/MM/YYYY") where needed.
Quick check: Would a first-time user know what to type without guessing?
3.3.3 (AA): Error suggestions are provided when known and safe.
What this means: If the system knows how to fix an error, it should suggest it.
How to do it on Wikidot: For validation messages, include specific guidance ("Password must be 12+ characters").
Quick check: Do error messages help users succeed, not just tell them they failed?
3.3.4 (A, WCAG 2.2 new): Redundant entry is avoided in multi-step processes (auto-populate or selectable).
What this means: Don’t make users retype the same info they already entered during the same process.
How to do it on Wikidot: Where possible, carry details forward, auto-fill, or provide a selection list.
Quick check: In a multi-step flow, are users repeatedly asked for the same thing?
4) Robust
4.1 Compatible
4.1.1 (A): Name/role/value are programmatically exposed for all UI components (including custom widgets); states/values update correctly.
What this means: Custom widgets must behave like real controls (buttons act like buttons, toggles announce on/off).
How to do it on Wikidot: Prefer standard links/buttons. If using custom scripts/components, ensure they support keyboard and work with screen readers.
Quick check: Do custom widgets work with keyboard and announce their state clearly?
4.1.2 (AA): Status messages are programmatically determinable without moving focus (success, errors, "saved", "loading", vote recorded, etc.).
What this means: When something updates (saved, error, loading), screen reader users should be informed without having to hunt for it.
How to do it on Wikidot: Theme/component work: ensure status messages are announced (e.g., via appropriate live-region patterns) and are visible too.
Quick check: If you submit/save/vote, do you get a clear confirmation that’s easy to notice?
4.1.3 (AA): All functionality retained to a minimum screen width of 326 pixels (no massive overflow, no massive side scroll, text wrapping handled appropriately, etc).
What this means: The page must remain readable and usable on very small screens. At 326px width, users should be able to read content and use all controls without the layout breaking, important elements being cut off, or needing constant left-right scrolling.
How to do it on Wikidot: Use responsive layouts, avoid hard-coded widths, allow text to wrap, make images scale to the page width, and provide alternate layouts for large tables (e.g., stacked rows or a summary + link).
Quick check: Resize your browser window (or use mobile view) to ~326px wide. You should be able to read paragraphs with only vertical scrolling, and all menus/buttons/forms should remain usable.
Per 
