[{"data":1,"prerenderedAt":206},["ShallowReactive",2],{"page:\u002Faccessibility\u002F":3},{"id":4,"title":5,"body":6,"dateModified":190,"datePublished":191,"description":192,"extension":193,"heroAlt":194,"heroImage":195,"layout":196,"meta":197,"navigation":198,"ogDescription":199,"ogImage":195,"ogTitle":200,"path":201,"schema":202,"seo":203,"stem":204,"__hash__":205},"content\u002Faccessibility.md","Accessibility",{"type":7,"value":8,"toc":177},"minimark",[9,21,26,29,32,35,38,42,45,48,51,54,57,61,64,67,79,82,86,89,92,95,98,102,105,108,111,114,117,121,124,127,130,133,136,140,143,146,149,152,155,159,162,165,168,171,174],[10,11,12,13,20],"p",{},"Blaskan is built with accessibility as a structural concern, not a post-development checkbox. This page covers how the theme approaches each major accessibility requirement: reading order, keyboard navigation, focus states, color contrast, line length, spacing, heading hierarchy, and link states. The search intent here includes both evaluation (does this theme meet accessibility standards before I commit to it?) and troubleshooting (why does this specific behavior work the way it does?). This documentation draws on over a decade of building accessible front-end layouts and reviewing themes against WCAG criteria in production environments. The ",[14,15,19],"a",{"href":16,"rel":17},"https:\u002F\u002Fwww.w3.org\u002FWAI\u002Fstandards-guidelines\u002Fwcag\u002F",[18],"nofollow","Web Content Accessibility Guidelines"," from the W3C Web Accessibility Initiative are the foundation for the standards referenced throughout this page.",[22,23,25],"h2",{"id":24},"reading-order","Reading Order",[10,27,28],{},"Reading order refers to the sequence in which content is encountered when navigating without visual reference, using a screen reader or keyboard-only navigation. The visual layout of a page can suggest one reading order while the underlying DOM presents content in a different sequence. When those two sequences diverge, screen reader users get a disorienting experience that has no visual equivalent.",[10,30,31],{},"Blaskan structures its templates so that DOM order matches visual reading order. In archive views, the header comes first in the DOM, followed by the main content area, then the sidebar, then the footer. On single posts, the structure is the same: header, content (including post title and body), sidebar, footer. The sidebar is positioned after the main content in the DOM even though it appears visually alongside the content column at desktop widths. CSS handles the visual column layout. The underlying content order does not change between desktop and mobile.",[10,33,34],{},"This means screen reader users and keyboard navigators encounter content in a predictable, logical sequence regardless of viewport width. Main content always comes before sidebar content in the reading order.",[10,36,37],{},"Avoid restructuring the DOM order in a child theme to achieve a visual effect. Moving the sidebar before the content in the HTML to achieve a left-sidebar layout at desktop widths creates a reading order problem for non-visual users. Use CSS positioning or flexbox order properties to change visual position without touching the DOM sequence.",[22,39,41],{"id":40},"keyboard-navigation","Keyboard Navigation",[10,43,44],{},"Every interactive element in Blaskan is reachable and operable by keyboard alone. This includes the primary navigation menu, submenu items, the search form input and submit button, the comment form, and all links within post content, widget areas, and the footer.",[10,46,47],{},"Tab order follows DOM reading order. Starting from the top of the page, focus moves through the header links, the primary navigation menu items, and then into the content area. Within the content area, links and form controls receive focus in the order they appear in the document.",[10,49,50],{},"The primary navigation menu at desktop widths supports full keyboard operation. Tab moves between top-level navigation items. When a top-level item has a submenu, arrow keys expand it and navigate within it. The Escape key closes an open submenu and returns focus to the parent item. This pattern matches the established keyboard interaction model for navigation menus and does not require custom documentation for keyboard users familiar with common patterns.",[10,52,53],{},"On mobile widths, the menu toggle button is keyboard-focusable and responds to both Enter and Space. Opening the menu reveals a vertical list of navigation items. Submenu items expand in-line below their parents. Focus is not trapped within the open mobile menu. Users can tab out of the navigation and continue into the page content at any point.",[10,55,56],{},"No keyboard traps exist in the default Blaskan templates. Focus is never forced to loop within a region without an exit path. This is a WCAG 2.1 Level A requirement, and it is met by default in all Blaskan page templates.",[22,58,60],{"id":59},"focus-states","Focus States",[10,62,63],{},"Focus states are the visible indicators that appear on interactive elements when they receive keyboard focus. Without clearly visible focus states, keyboard users cannot reliably track their position on the page. This is one of the most frequently broken accessibility requirements in custom themes.",[10,65,66],{},"Blaskan provides visible focus states on all interactive elements by default: links, buttons, form inputs, and textareas. The focus style uses a combination of outline and color change to ensure visibility against the default theme background and text colors. The styling is intentionally clear rather than decorative.",[10,68,69,70,74,75,78],{},"The default focus styles are not suppressed by any general ",[71,72,73],"code",{},"outline: none"," or ",[71,76,77],{},"outline: 0"," rule in the theme stylesheet. Many themes apply a blanket outline removal to avoid the browser's default focus ring, then fail to add any replacement. The result is a site where keyboard users cannot see where focus is. Blaskan avoids this pattern entirely.",[10,80,81],{},"If you are applying custom CSS in a child theme, check that your rules do not unintentionally suppress focus indicators. The most common failure pattern is a broad selector targeting all anchor elements or all button elements that resets their outline without providing an alternative. Any custom CSS that modifies focus-related properties should be tested by navigating the affected elements with the keyboard and confirming that focus is visible at each stop.",[22,83,85],{"id":84},"color-contrast","Color Contrast",[10,87,88],{},"Blaskan's default color palette is designed to meet WCAG AA contrast requirements for normal text. The primary text color against the default background color produces a contrast ratio above 4.5:1. Heading text, link text, and meta text all meet or exceed this threshold in the default configuration.",[10,90,91],{},"Body text contrast is the most consequential single contrast decision in a theme. Text that fails minimum contrast thresholds affects every visitor reading under less than ideal conditions: lower screen brightness, ambient light on the screen, aging vision, or non-calibrated displays. Light gray text on white backgrounds is the most common failure case. It looks acceptable during development on a bright, calibrated monitor and fails for a significant portion of real visitors.",[10,93,94],{},"Link text in the content area is differentiated from surrounding body text by both color and underline. This meets the WCAG requirement that links not rely on color alone to distinguish them from non-link text. The underline is not cosmetic. It is a functional accessibility signal.",[10,96,97],{},"When you apply custom colors through the Customizer or through a child theme, verify the resulting contrast ratios before publishing. Do not rely on visual assessment alone. Tools like the WebAIM Contrast Checker produce exact ratios for any two hex values. The threshold to verify is 4.5:1 for normal body text and 3:1 for large text (18pt or 14pt bold). Colors that look readable are not always passing. Check the number.",[22,99,101],{"id":100},"line-length","Line Length",[10,103,104],{},"Line length affects reading comfort and comprehension in measurable ways. Very long lines cause readers to lose their place when returning from the end of one line to the start of the next. Very short lines fragment text and interrupt reading rhythm by forcing the eye to change direction too frequently.",[10,106,107],{},"The Blaskan content column width is controlled by the theme CSS. At full desktop widths, the content column produces line lengths in the range of 60 to 75 characters per line for body text at the default font size. This is within the widely cited recommended range for on-screen reading.",[10,109,110],{},"The sidebar column is narrower. Widget content in the sidebar produces shorter lines. This is acceptable for the discrete, navigational content that sidebars typically hold. Longer-form text does not belong in the sidebar.",[10,112,113],{},"As the viewport narrows through responsive breakpoints, the content column width adjusts. Line length shortens at smaller sizes. At mobile widths, the content column fills the viewport width minus margin padding, which produces slightly shorter lines than the desktop range but stays within readable territory for standard mobile font sizes.",[10,115,116],{},"If you increase the body font size through custom CSS, verify that the resulting character count per line remains in an acceptable range. Larger text in the same column width produces fewer characters per line. Enough size increase can push the layout into uncomfortably short-line territory even when the column width has not changed.",[22,118,120],{"id":119},"spacing","Spacing",[10,122,123],{},"Spacing in Blaskan serves multiple purposes simultaneously. It separates distinct content elements visually, creates breathing room around text blocks, and contributes to the reading rhythm of the page at every level from paragraph to archive stream.",[10,125,126],{},"Paragraph spacing uses margin-bottom on the paragraph element rather than line-height inflation within the paragraph. This creates visible separation between paragraphs without requiring empty lines in the source content. The distinction matters when users paste content from word processors that rely on empty paragraphs for spacing.",[10,128,129],{},"The vertical spacing between post cards in the archive view is handled consistently: margin applied across card boundaries produces a rhythm that matches the internal rhythm of individual post content. Archive and single post views feel like the same system rather than separate designs.",[10,131,132],{},"Heading spacing uses a combination of margin-top and margin-bottom to create visible separation from surrounding content. Headings are visually closer to the content they introduce than to the content above them. This spacing pattern helps readers understand which content belongs under which heading during a fast scan.",[10,134,135],{},"Customizing spacing values carries a readability risk that is easy to underestimate. Reducing paragraph spacing or heading margins to fit more content on screen is a common impulse during customization. The gain is rarely worth the cost. Compressed spacing degrades reading comfort before any meaningful content benefit is achieved.",[22,137,139],{"id":138},"heading-hierarchy","Heading Hierarchy",[10,141,142],{},"Blaskan enforces a consistent heading hierarchy across its templates. The page title or post title uses an H1. Within post content, the first available heading level for section headers is H2. Subheadings within those sections use H3. The hierarchy does not skip levels.",[10,144,145],{},"This matters for screen reader navigation. Screen reader users frequently navigate pages by heading level, jumping between H2 elements to find the section they want without reading the full page. A heading hierarchy that skips levels or that uses heading elements for non-heading purposes (decorative titles, pull quotes, styled widget labels) degrades this navigation experience.",[10,147,148],{},"The sidebar widget area uses heading elements for widget titles. These are set at a level that remains subordinate to the main content headings and does not create a hierarchy conflict. Widget title headings are part of the sidebar, not the main content region.",[10,150,151],{},"When adding content to a Blaskan-based site, follow the heading hierarchy that the templates establish. Starting content headings at H2 is the correct pattern. Adding an H1 inside post content creates a page with two H1 elements, which creates ambiguity for both screen readers and search indexing. Starting content headings at H3 leaves an empty H2 level, which creates gaps that confuse heading-based navigation.",[10,153,154],{},"Custom page templates or sidebar widgets that add heading elements should be checked against the existing heading hierarchy before deployment.",[22,156,158],{"id":157},"links-and-states","Links and States",[10,160,161],{},"Links in Blaskan have four distinct states: default, visited, hover, and focus. Each state is styled differently to provide clear feedback about link status and interactive behavior.",[10,163,164],{},"The default link color is visually distinct from surrounding body text. It includes an underline. This combination ensures links are recognizable even to visitors who cannot distinguish colors reliably.",[10,166,167],{},"The visited link color differs from the default link color. This distinction helps users track which content they have already seen when scanning an archive or following a series of related posts. Many custom themes eliminate visited link styling as an aesthetic choice, removing a useful navigation signal.",[10,169,170],{},"The hover state changes the link color and the cursor switches to a pointer. This provides immediate visual confirmation that the element is interactive before a click or tap.",[10,172,173],{},"The focus state applies the same visible focus styling used on other interactive elements: a visible outline. Links in post content, navigation, and widget areas all show focus state when reached by keyboard navigation.",[10,175,176],{},"Avoid custom CSS that removes underlines from all links without providing a replacement visual differentiator. Underline removal is common for aesthetic reasons. Links that rely solely on color to distinguish them from surrounding body text fail WCAG success criterion 1.4.1, which requires that color not be the only visual means of conveying information. If you remove underlines from content links, replace them with a border-bottom, background highlight, or other non-color indicator that applies in both default and visited states.",{"title":178,"searchDepth":179,"depth":180,"links":181},"",2,3,[182,183,184,185,186,187,188,189],{"id":24,"depth":179,"text":25},{"id":40,"depth":179,"text":41},{"id":59,"depth":179,"text":60},{"id":84,"depth":179,"text":85},{"id":100,"depth":179,"text":101},{"id":119,"depth":179,"text":120},{"id":138,"depth":179,"text":139},{"id":157,"depth":179,"text":158},"2026-01-15","2024-05-10","How the Blaskan WordPress theme approaches accessibility: reading order, keyboard navigation, focus states, color contrast, line length, spacing, heading hierarchy, and link states.","md","Accessibility guidelines diagram showing focus states, contrast ratios, and reading order for Blaskan theme","\u002Fimages\u002Fhero\u002Faccessibility-1600x900.jpg","default",{"heroLabel":5},true,"How Blaskan handles accessibility: keyboard navigation, focus states, color contrast, line length, heading hierarchy, and link states.","Blaskan Accessibility","\u002Faccessibility","article",{"title":5,"description":192},"accessibility","X0Ne0VXxTA1NAeZRuRX874fk3B28wBc130o0UUMY1RA",1775942364845]