Accessibility
Michigan Legal Publishing Ltd. is committed to making Court Rules Network accessible to everyone, including people who use assistive technologies such as screen readers, voice control software, or keyboard-only navigation.
Conformance status
We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. Court Rules Network is partially conformant with WCAG 2.1 Level AA. "Partially conformant" means that some content does not yet fully conform to the standard. We are actively working to address known gaps.
What works well
- Keyboard navigation. All interactive elements (navigation menus, tabs, forms, links, and the interactive circuit map) are reachable and operable by keyboard alone. The tab widget on rule pages supports arrow-key navigation (Left/Right/Home/End) per WCAG 2.1 guidelines.
- Skip to main content. A skip link appears at the top of every page, allowing keyboard users to bypass repeated navigation and jump directly to page content.
- Screen reader support. Pages use semantic HTML5 elements (
<main>,<nav>,<header>,<footer>,<article>) with ARIA labels where needed. Tab panels, navigation landmarks, and interactive controls are labeled for assistive technology. - Focus management. The disclaimer notice that appears on first visit moves keyboard focus to the acknowledgment button, traps focus within the dialog while it is open, and dismisses on Escape. Links within the disclaimer are underlined for non-color identification.
- Breadcrumb navigation. All pages include a breadcrumb trail using
<nav aria-label="Breadcrumb">with the current page marked viaaria-current="page", so screen reader users can orient themselves within the site hierarchy. - Color and contrast. All text meets WCAG AA contrast ratios (4.5:1 minimum for normal text, 3:1 for large text). This includes body text, badges, search result labels, navigation items on hover states, hero section text, and decorative accent colors on cards. We do not rely on color alone to convey information; links in dialogs are underlined, and active navigation items are marked with
aria-current. - Circuit map. The interactive federal circuits map uses an inline SVG with
aria-labelon each clickable state (e.g., "Alabama — 11th Circuit") and visible keyboard focus indicators, so screen reader and keyboard users can navigate the map. - Data tables. Judge rosters and local rule tables use proper
<thead>,<th scope="col">, andaria-describedbylinking tables to their section headings. - External links. Links that open in a new tab include
aria-labeltext indicating this behavior (e.g., "Official Court Website (opens in new tab)"). - Form accessibility. All form fields have associated labels, and identity fields (name, email) include
autocompleteattributes per WCAG 1.3.5. Dropdowns includearia-labelwhen a visible label is not present. - Semantic headings. All pages follow a logical heading hierarchy (h1 through h3). Footer navigation columns and the disclaimer dialog use proper heading elements for screen reader landmark navigation.
- Touch targets. Interactive elements (buttons, tabs, FAQ toggles) meet a minimum size of 44px for touch accessibility.
- Dynamic content. Content that updates dynamically (such as local rule overlays) uses
aria-live="polite"to announce changes to screen readers. - Text resizing. Page layouts are fluid and respond correctly when browser text size is increased up to 200% without loss of content or functionality.
- No time limits. No content times out or auto-advances.
- No flashing content. Nothing on this site flashes more than three times per second.
- Self-hosted fonts. All fonts are hosted on our servers and load with
font-display: swap, so readable system fonts are shown immediately while custom fonts load. - Structured data. Every public page includes JSON-LD structured data (BreadcrumbList, LegalDocument, GovernmentOrganization, etc.) that helps search engines and assistive tools understand page content and relationships.
Known limitations
- Rule text complexity. Federal and state rule text can be highly nested, with multiple levels of indentation. While we mark up subsections using semantic list-like formatting, some complex tables within rule text may not fully convey their structure to screen readers.
- Circuit map detail. The interactive circuit map conveys state-to-circuit relationships visually through color coding. While each state has an accessible label, the overall geographic context may be difficult for users who cannot see the map. The same information is available in text form in the circuit sections below the map.
- Local rule text formatting. Local district court rules are extracted from court PDFs. The extracted text preserves content but may not retain the original formatting or visual hierarchy of the source document.
- No formal AT testing. We have not yet conducted formal testing with real screen reader users or with automated accessibility audit tools on every page. We rely on manual review and ARIA best practices.
Supported assistive technologies
We design for compatibility with commonly used assistive technologies, including:
- Screen readers: NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari on macOS and iOS
- Voice control: Dragon NaturallySpeaking, Voice Control on macOS/iOS
- Keyboard-only navigation in all major browsers
- Browser zoom up to 200%
Technical approach
This site is built with standard HTML5, CSS, and minimal JavaScript. We use ARIA roles and attributes where HTML semantics alone are insufficient. We do not use Flash, PDF-only content, or other formats known to present accessibility barriers for rule text display. No content requires JavaScript to read; rule text, summaries, court information, and navigation are all server-rendered HTML. The interactive circuit map uses an inline SVG with accessible link elements rather than a raster image or canvas.
Feedback and contact
If you encounter an accessibility barrier on this site (a difficult page, content that is hard to read with assistive technology, or any other issue), please contact us. We take these reports seriously and will work to address them.
We aim to respond to accessibility feedback within five business days.