Listen reads the visible page text. Open any details you want included before starting. Event buttons read that event’s dates and notes. Images, videos and external feeds are not narrated.
Pause, resume or stop at any time. Press Escape to stop. Resuming or changing voice or speed may repeat a short passage. Reading pauses when you leave this tab and stops if the text changes.
Choose a voice you enjoy. Automatic prefers Google UK English Male when available, with other English voices as fallbacks. Voice quality and choices depend on your browser and device. Voices labeled Online may send page text to your browser’s voice provider. Choose an On-device voice if you prefer local speech. No microphone is needed. You can continue using your own screen reader.
Our target is WCAG 2.2 Level AAA. Full AAA conformance has not been verified. This report explains what has been built, what has been checked, and what still needs review. It is an implementation and evidence record, not a certificate or a claim that the site meets every requirement.
This review covers all 86 active WCAG 2.2 success criteria at Levels A, AA and AAA. Each entry links to the full W3C requirement. Our evidence does not restate every condition or exception.
The PDF contains the same report as this page. It includes document tags and bookmarks; screen-reader behavior and PDF/UA conformance have not been verified.
Scope and evidence
The criterion review covers the six original HTML pages: Home (/), Explore (/explore/), Photos (/photos/), Plan your visit (/visit/), Sources (/sources/), and Accessibility (/accessibility/), plus the missing-page response. The reviewed baseline is the October 8, 2026 site release.
The photo dialog, FAQ disclosures, reading preferences and weather section are included. Live forecasts and alerts are supplied by the National Weather Service. Future alert messages and every possible provider response have not been reviewed.
Linked city documents, maps, reservation sites and social platforms are outside this website review. These are ordinary links; the content is not embedded. Park facilities and physical accessibility are outside this report.
This report page and downloadable PDF were added after the baseline review. Their links, structure and presentation receive separate publication checks; the 86 criterion entries do not claim a completed audit of these new documents. The same report is available as HTML for readers who prefer browser access.
Checks recorded
Automated checks: axe-core 4.14.0 reported no violations or incomplete checks on the seven original page templates, using WCAG A/AA, 2.1 AA, 2.2 AA and the AAA rules supported by that tool. Automation covers only part of WCAG.
Keyboard checks: the skip link, FAQ disclosure and gallery were exercised. The photo dialog keeps Tab focus between its controls, closes with Escape and returns focus to the photo that opened it.
Display checks: narrow layouts were checked at 320 CSS pixels with no horizontal overflow. Text enlargement smoke checks were performed at 200% font size. A full browser zoom, orientation, text-spacing and assistive-technology test matrix is still needed.
Content and source checks: page titles, headings, image alternatives, landmarks and shared navigation were inspected. Main text colors and control sizes were strengthened. Not every rendered state or image description has received a complete manual assessment.
Weather checks: four automated tests covered current data, forecast failure, alert failure and expired data. A failed alert lookup is reported as unknown. A production lookup returned current forecasts and no active alerts; this is a point-in-time observation.
Technologies
The HTML site uses HTML5, CSS, JavaScript, native links, buttons, select, details/summary and dialog, plus WAI-ARIA labels and status messages. Images are WebP. Testing recorded here used desktop Chrome on Windows. No screen-reader/browser support matrix has been completed. The PDF is a separate document format.
How to read the statuses
Evidence recorded
Implementation or test evidence is available. This does not mean that every part of the requirement has passed.
Needs manual review
The available evidence is not enough, or an implementation issue needs review before the requirement can be marked as met.
Not applicable
The feature covered by this requirement is absent from the reviewed pages. Reassess this if features or content change.
These are evidence statuses, not pass/fail ratings. Criterion 4.1.1 Parsing was removed from WCAG 2.2 and is not included in the 86 active entries.
1. Perceivable
Can people receive the information through the senses and formats available to them?
1.1.1 Non-text Content
Level A · Needs manual review
Evidence: The build supplies descriptive alternatives for park photographs and named gallery buttons. The photo dialog copies the selected image alternative; the decorative brand initial is hidden from assistive technology. Source presence does not establish equivalent meaning or useful screen-reader output.
Next step: Compare every photograph with its alternative, then check gallery announcements using a screen reader.
Evidence: The current HTML pages contain photographs, written visitor information and text weather data. The source includes no prerecorded audio-only player, silent video or embedded media requiring an alternative under this criterion.
Next step: Reassess before adding prerecorded audio, silent video or embedded media to these HTML pages.
Evidence: No prerecorded synchronized audio and video is embedded in the current HTML pages. The park photo gallery uses still images with written captions, which are not synchronized-media captions assessed by this criterion.
Next step: Require accurate synchronized captions if narrated video or other prerecorded synchronized media is introduced.
1.2.3 Audio Description or Media Alternative (Prerecorded)
Level A · Not applicable
Evidence: The reviewed HTML templates contain no prerecorded synchronized media. Park attractions are described in text and still photographs, so no video sequence currently requires audio description or a complete media alternative.
Next step: Assess the visual information and alternative format before publishing any prerecorded synchronized media.
Evidence: The current HTML pages have no live audio or video broadcasts. National Weather Service forecasts and alerts update as text; those data updates do not constitute live synchronized media needing captions.
Next step: Review live-caption arrangements before embedding any live broadcast with synchronized audio and video.
Evidence: There is no prerecorded synchronized media in the reviewed HTML source. The train, playground, paths and shelters are presented through written descriptions and photographs rather than video content with an audio track.
Next step: Provide and review audio description when future prerecorded video conveys relevant information visually.
Evidence: The HTML visitor guide contains no prerecorded audio within synchronized media. Still photographs, written park information and text-based weather updates do not introduce the media content addressed by this criterion.
Next step: Include sign-language interpretation planning if prerecorded synchronized audio content is added to the guide.
Evidence: No prerecorded synchronized video is present in the current HTML pages. Consequently, there are no video timing constraints to assess for whether ordinary pauses can accommodate descriptions of meaningful visual information.
Next step: Assess description timing and extended-description needs before publishing any prerecorded synchronized video.
Evidence: The reviewed HTML pages contain neither prerecorded synchronized media nor prerecorded video-only content. Written park descriptions and still-image captions are present, but no time-based presentation currently requires a complete text media alternative.
Next step: Prepare a complete media alternative if prerecorded video or synchronized media is introduced.
Evidence: The HTML source has no live audio stream or audio-only event coverage. Weather refreshes display written forecast and alert information, without generating an audio broadcast on these pages.
Next step: Arrange an equivalent text alternative before introducing any live audio-only presentation on the site.
Evidence: Templates use headings, landmarks, lists, description lists, figure captions and an explicitly associated Display label. Weather periods use headings and alerts use native disclosures. Automated results are recorded, but relationships across rendered states still need assistive-technology review.
Next step: Inspect the accessibility tree and screen-reader structure on every template, including expanded alerts and the photo dialog.
Evidence: The document sequence places navigation, page content and footer in order, and responsive grids do not use CSS ordering. Forecast periods and alert text are inserted sequentially. A complete reading-order check with styles disabled or assistive technology is undocumented.
Next step: Read every template linearly, including loaded weather, expanded disclosures and the open photo dialog.
Evidence: Static instructions identify controls by words such as Refresh weather, Display and Close. Photo instructions say to select a photo. No static instruction found depends solely on shape, color or position, but dynamic NWS instructions remain unreviewed.
Next step: Review all instructions in rendered pages and representative NWS alerts for dependencies on sensory characteristics.
Evidence: The responsive CSS uses width breakpoints and the source contains no orientation lock or orientation-specific content restriction. The recorded 320-pixel check supports narrow layouts but does not document complete portrait and landscape operation on mobile devices.
Next step: Check portrait and landscape on mobile, including navigation, reading controls, weather disclosures and the photo dialog.
Evidence: The current HTML pages collect no names, contact details, addresses or other information covered by the criterion's defined input purposes. The Display selector changes a local reading preference; reservations and email contact use external links.
Next step: Reassess defined input purposes and appropriate autocomplete values if personal-information fields are added.
Evidence: Header, navigation, main and footer landmarks identify page regions; native controls and text labels expose several functions. These source features do not establish that all component, icon and region purposes can be programmatically determined for personalization.
Next step: Inventory component and region purposes, then verify their programmatic identification using accessibility-tree and personalization checks.
Evidence: The pool notice states its meaning in text. Weather availability and alert outcomes use written messages, and active navigation includes an underline and aria-current. Reading modes change colors without replacing labels or textual status information.
Next step: Confirm every rendered state remains understandable without color, particularly loading, failure and active-alert states.
Evidence: The current HTML pages contain no audio player, autoplaying media or script-generated sound. Weather refreshes, photo enlargement and display-preference changes operate through visual text and interface updates without site-generated audio.
Next step: Reassess audio controls before adding autoplaying sound, media embeds or audible site notifications.
Evidence: The stylesheet darkens muted text, uses solid caption backgrounds and offers a black-and-white reading mode. README records no automated violations for tested templates. A complete measured contrast inventory covering text sizes, control states and dynamic weather is not recorded.
Next step: Measure rendered text contrast in every display mode and state against the applicable minimum thresholds.
Evidence: Text largely uses rem units and the viewport permits scaling. A 200% font-enlargement check is recorded, but font enlargement is not equivalent evidence of 200% browser zoom. Complete enlarged-state coverage, including weather and the photo dialog, remains undocumented.
Next step: Test 200% browser zoom and text resizing across templates and interactive states for lost content or functionality.
Evidence: Headings, branding, buttons, notices, captions and weather information are generated as HTML text. Assets are park photographs rather than text graphics. The entrance-sign photograph includes environmental lettering as part of its depiction of the park.
Next step: Visually inspect the image inventory and retain real text for any future informational graphics.
Evidence: Stronger muted-text colors and the black-and-white display option support the AAA target. Automated checks are useful evidence, but no complete record demonstrates enhanced contrast for every rendered text pair, text size, reading mode and weather state.
Next step: Measure all relevant rendered text pairs against enhanced thresholds and document how any qualifying alternative mode is reached.
Evidence: The current HTML pages provide no prerecorded audio-only speech content. Visitor information and National Weather Service data are displayed as text, so there is no foreground speech and background-audio mix to assess.
Next step: Review background levels and available controls if prerecorded audio-only speech is added to the guide.
Evidence: Prose has limited line widths and nonjustified text. Roomy and black-and-white modes add paragraph spacing; the site also describes browser adjustments. These features do not establish all required presentation choices or enlarged-text behavior for every text block.
Next step: Verify color choices, line length, line and paragraph spacing, and 200% resizing throughout pages and dynamic content.
Evidence: The generated interface presents text using HTML, including the brand and photo captions. Current assets depict park scenes. Lettering within the entrance-sign photograph is part of the photographed setting; no separate text-only promotional image appears in the source inventory.
Next step: Confirm image contents visually and ensure future additions use real text unless an allowed exception applies.
Evidence: README records no horizontal overflow at 320 CSS pixels. Layouts collapse to single columns, navigation wraps and long prose links can break. The recorded check does not establish content and functionality preservation across every dialog, reading mode and lengthy alert state.
Next step: Repeat 320-CSS-pixel and equivalent zoom checks with all display modes, expanded alerts and the photo dialog.
Evidence: Buttons and the Display selector have visible boundaries; keyboard focus uses contrasting outlines, with special colors on dark backgrounds. Forced-colors rules also exist. Source colors alone do not verify required contrast for identifying every component and state.
Next step: Measure essential component boundaries and state indicators against adjacent colors in each reading mode and rendered state.
Evidence: The CSS uses generous line height, flexible layouts and optional additional paragraph spacing. No documented check applies all four required spacing overrides simultaneously, and the presets do not establish resilience of captions, navigation, weather alerts or dialog controls.
Next step: Apply the specified line, paragraph, letter and word spacing overrides simultaneously and check every template and interactive state.
Evidence: The current HTML interface has no custom tooltip or supplementary panel triggered by hover or focus. Photos and disclosures open on activation. The focused skip link reveals the control itself rather than additional content covered by this criterion.
Next step: Reassess dismissibility, hoverability and persistence if hover- or focus-triggered supplementary content is added.
Can people navigate and use the site with different input methods and enough time?
2.1.1 Keyboard
Level A · Evidence recorded
Evidence: The HTML guide uses native links, buttons, disclosure summaries and a select control. README records successful keyboard checks for skip navigation, FAQs and the photo dialog, including Tab wrapping, Escape and return focus.
Next step: Complete keyboard walkthroughs of every page, display option and weather success or failure state.
Evidence: The photo dialog intentionally cycles Tab between its controls. Recorded testing verified Escape closes it and returns focus to its opener. Native FAQ disclosures and the skip link were also exercised without a recorded trap.
Next step: Repeat the dialog exit and return sequence in supported browsers and screen reader combinations.
Evidence: Current HTML interactions involve opening photos, expanding FAQs, choosing display preferences and refreshing weather. None requires a drawn path or timed keystroke. Recorded keyboard checks cover the gallery and navigation, with broader assistive technology coverage outstanding.
Next step: Verify every interactive state remains keyboard operable without relying on any exception for pointer movement.
Evidence: The current browser script implements Tab handling inside the photo dialog and relies on native Escape behavior. It defines no shortcuts activated by letters, numbers, punctuation or symbols alone anywhere in the HTML guide.
Next step: Reassess if future gallery navigation or other controls introduce single character keyboard shortcuts.
Evidence: The HTML guide sets no deadline for reading, choosing display settings or using the gallery. Weather request timeouts limit network waiting and display an error; they do not impose a timed user response or expire entered information.
Next step: Check future booking, login or form features for user time limits before release.
Evidence: The guide contains static photographs rather than autoplay media, tickers or slideshows. Weather loads once on page entry and again only after Refresh weather is activated. There is no repeating background refresh or persistent moving information.
Next step: Reassess if recurring weather refreshes, animated media or automatically advancing photo galleries are added.
Evidence: Reading park information, exploring photos, opening FAQs and selecting display preferences have no timed interaction requirement. The weather fetch timeout only ends a network attempt; visitors can continue reading and request another update at any time.
Next step: Preserve untimed visitor interactions when expanding the site with new services or account features.
Evidence: The weather section announces loading and completion through its status text during initial loading or a requested refresh. No recurring timer, advertisement or unsolicited modal appears in the source. Screen reader interruption behavior has not been fully evaluated.
Next step: Check weather announcements with screen readers while reading nearby content; prevent unnecessary disruption or repeated announcements.
Evidence: The HTML visitor guide has no authentication, account session or protected task. Reservations are links to external city services, outside this assessment. Display preferences are stored locally without a login or authentication expiry.
Next step: Reassess if authenticated accounts or reservation workflows are later implemented within the guide.
Evidence: The guide collects no unfinished form submissions and has no user inactivity timeout. Local display preferences persist. Weather data freshness limits and request timeouts affect displayed service information, not loss of a visitor's work.
Next step: Reassess any future form or account feature that could discard information after inactivity.
Evidence: Current HTML pages contain still WebP photographs, text and native controls. The stylesheet includes no flashing animation, and the script does not alternate bright visual states repeatedly. Weather changes replace text following a single request.
Next step: Inspect newly added images, videos and animations for flash hazards before incorporating them into the guide.
Evidence: No flashing content is present in the reviewed HTML source or static photography. Gallery photographs change only when visitors open another image. The weather interface updates on initial loading or explicit refresh without repeated visual flashing.
Next step: Keep future animated assets and interaction effects free of flashing sequences across all page states.
Evidence: The stylesheet enables smooth scrolling but changes it to automatic scrolling when reduced motion is requested. The same media query disables animation and transitions. Gallery opening and weather refresh have no authored motion animation in the current script.
Next step: Verify reduced motion behavior in supported browsers and retain the override when adding interface effects.
Evidence: Every generated HTML template, including the error page, starts with a skip link to the main region. The destination has tabindex minus one. README records a successful manual skip navigation check during launch verification.
Next step: Repeat skip navigation testing across all templates after changes to the shared header or layout.
Evidence: The build generates distinct HTML titles for Home, Explore, Photos, Plan your visit, Sources and Accessibility. The error document has its own Page Not Found title. Launch verification records unique page titles across the templates.
Next step: Keep titles descriptive and distinct when adding new HTML pages or changing their primary purpose.
Evidence: The shared header, main content and footer follow document order without positive tabindex values. Gallery wrapping and return focus were verified. A complete sequential focus review across display controls, responsive layouts and weather alert states remains outstanding.
Next step: Walk the full Tab sequence on every template, including loaded alerts, refreshed weather and each display mode.
Evidence: Most HTML links describe destinations such as shelter reservations, park directions and photo credits. Short labels also appear beside explanatory prose. A complete human review of each link's accessible name and programmatically associated context has not been recorded.
Next step: Review all links with their accessible context, including telephone numbers, historical sources and generated weather references.
Evidence: Header navigation exposes Explore, Photos and Plan your visit, while contextual links supplement some routes. Footer links expose Sources and Accessibility. An XML sitemap exists, but a second usable navigation method for every content page is not established.
Next step: Verify two distinct navigation methods for each content page; add a visible site index where necessary.
Evidence: Generated pages have one main heading and topic headings for activities, visitor details and accessibility information. Display and weather controls have visible labels. Some introductory headings use figurative wording, so their clarity needs a complete human review.
Next step: Review headings and control labels for clear topic descriptions without relying on surrounding imagery or layout.
Evidence: The stylesheet supplies three pixel outlines for links, buttons, summaries, focusable regions and the display selector, with alternate colors on dark sections. Keyboard checks were recorded, but visible focus was not exhaustively reviewed across every interactive state.
Next step: Inspect each focused control in all display modes, responsive layouts and weather or gallery states.
Evidence: Subpages include a Home breadcrumb and their current heading. Main navigation marks matching destinations with aria-current, while browser titles distinguish each document. The error template explicitly identifies a missing page and offers a home link.
Next step: Confirm current page cues remain understandable when visiting Sources, Accessibility and deep links directly.
Evidence: Many links name their destinations, but labels such as About this update and Get directions depend on nearby park context. Telephone links and source references also require an isolated accessible name review before a link only determination.
Next step: Inspect the screen reader links list and strengthen any name that lacks a clear standalone purpose.
Evidence: The guide divides activity descriptions, visitor information, FAQs, sources and accessibility guidance into headings. Weather forecast cards receive period headings, and alerts use disclosure summaries. This source review records structure without claiming a complete content organization audit.
Next step: Review longer source and weather alert sections for missing descriptive headings as their content changes.
Evidence: The HTML guide has no sticky header or persistent consent overlay. Its modal photo viewer contains keyboard focus, and skip navigation was tested. Every focusable component has not been checked for total obscuration at all viewport sizes.
Next step: Tab through every state at narrow widths and enlarged text, confirming each focused component remains partly visible.
Evidence: The photo dialog is the main authored overlay and keeps focus within its controls. Ordinary content uses flowing layouts without a fixed navigation bar. Complete visibility of every focused component has not been measured in all responsive states.
Next step: Verify no portion of any focused component is hidden in gallery, weather and display preference states.
Evidence: Three pixel outline rules and dark section color overrides provide explicit focus styling. These are promising source evidence, but minimum indicator area and contrast between focused and unfocused pixels have not been exhaustively measured for every control.
Next step: Measure indicator area and state contrast for each control type, including wrapped links and all display modes.
Evidence: The HTML gallery opens photographs with ordinary buttons; visitors do not pinch, swipe along a prescribed path or use multiple pointers. FAQ expansion, weather refresh and display selection also use simple native control activation.
Next step: Reassess if future map, gallery or other interfaces introduce complex gestures or multiple pointer actions.
Evidence: Gallery and weather actions are attached to click events rather than pointer down events. FAQ summaries, links and the display select use native activation behavior. No custom pointer down handler triggers an action before release.
Next step: Verify pressing and moving away cancels activation on representative controls using mouse and touch.
Evidence: Visible text supplies names for ordinary links, buttons and the display selector. Gallery buttons have explicit enlargement labels, and the header brand has an aria-label. All visible wording and computed names have not been compared systematically.
Next step: Compare visible labels with computed accessible names, then exercise representative controls through speech input.
Evidence: The reviewed guide uses no device motion, orientation sensor or camera gesture events to trigger functions. Photographs, weather and display options are operated through standard controls. There is no shake or tilt interaction to disable.
Next step: Reassess if device movement or camera gesture controls are introduced in later versions of the guide.
Evidence: CSS gives navigation, brand, breadcrumb and source links forty four pixel minimum dimensions, with comparable sizing on other controls. Gallery buttons are large. Every rendered target, inline exception and equivalent target has not been individually measured.
Next step: Measure all applicable targets at supported breakpoints and document any inline, equivalent or native control exception.
Evidence: The guide relies on native controls and does not branch on pointer type to disable keyboard or touch input. Gallery scripting handles clicks and keyboard focus. Switching among input methods has not been comprehensively tested on hybrid devices.
Next step: Switch between keyboard, mouse and touch during gallery, display and weather interactions without reloading the page.
Evidence: No interface in the HTML guide requires dragging an object, slider or map. Photographs enlarge through buttons, and display preferences use a native select. Weather refresh and FAQs also use simple activation rather than dragging.
Next step: Reassess any future draggable controls and provide a single pointer alternative before publishing them.
Evidence: The site's authored size rules generally exceed twenty four pixels for major controls, and launch automation reported no supported violations. However, every target and spacing exception has not been measured, including wrapped links and narrow screen arrangements.
Next step: Measure remaining target boxes and spacing at responsive widths, recording the applicable exception for any smaller target.
Are the words, navigation and controls clear and predictable?
3.1.1 Language of Page
Level A · Evidence recorded
Evidence: The shared page generator declares lang="en-US" on all six main HTML pages; the separate error template declares lang="en". The reviewed visitor information is English, and README records automated checks across all seven templates.
Next step: Retain these declarations and verify language announcements with a screen reader on every page template.
Evidence: Reviewed static content is English throughout, including the glossary and accessibility statement. Terre Haute and other location names appear as proper names. Weather descriptions and alert instructions are inserted from National Weather Service responses without per-part language markup.
Next step: Review representative alert responses and mark any genuine language changes introduced by future editorial or service content.
Evidence: The Explore page explains arboretum and disc golf, while the Accessibility page supplies a glossary. Marketing phrases and dynamically supplied weather alert terminology have not received a complete review for unusual meanings, idioms, or specialist jargon.
Next step: Review every page and representative weather alerts; define unfamiliar expressions beside the text or in an accessible glossary.
Evidence: The Accessibility glossary expands NWS, WCAG, AAA, PDF, IN, degrees Fahrenheit, and mph. Weather rendering expands common wind directions and miles per hour. Abbreviations within unmodified National Weather Service alert descriptions and instructions remain unverified.
Next step: Inventory abbreviations in static pages and sampled alerts, then provide expansions for every uncovered abbreviation.
Evidence: Visitor pages use short sections and concrete planning information, with explanations of arboretum and disc golf. README explicitly leaves reading-level checks outstanding. No documented reading-level assessment covers all static copy or dynamically supplied National Weather Service alerts.
Next step: Assess static copy and representative alert text; provide simpler explanations or supplemental content wherever the criterion requires them.
Evidence: The guide contains local place names and a text glossary, but no pronunciation mechanism or documented pronunciation review. Source inspection does not establish whether any words, including those in changing weather alerts, require pronunciation to disambiguate their meaning.
Next step: Review wording in context for pronunciation-dependent ambiguity and add a pronunciation aid where an actual ambiguity is found.
Evidence: The browser script contains click and change handlers for photo viewing, display settings, and weather refresh; no focus handler triggers navigation or opens content. README records keyboard checks of the skip link, disclosures, and photo viewer.
Next step: Complete a keyboard and screen-reader walkthrough confirming that focusing each available control never changes context.
Evidence: The only editable form control is the Accessibility page's Display select. Its change handler applies a display preference locally, stores the choice, and updates a status message. It does not submit information, navigate, or programmatically move focus.
Next step: Test all three options using keyboard and assistive technology, confirming focus remains on the selector.
Evidence: A shared header generates Explore, Photos, and Plan your visit in the same order across the six main pages and error page. The shared footer likewise preserves Sources, Accessibility, and Official parks department link order.
Next step: Confirm the generated order remains consistent across desktop, narrow layouts, enlarged text, and future page additions.
Evidence: The shared templates preserve labels for recurring navigation, sources, accessibility, and park-department links. Gallery buttons consistently use an Enlarge photo prefix with the photo title. The same display preference and weather refresh controls are not duplicated under conflicting labels.
Next step: Compare repeated controls in rendered pages, including their accessible names, to verify that equivalent functions retain consistent identification.
Evidence: Photo dialogs open on button activation; navigation follows link activation. The weather panel fetches once on load or after Refresh weather and replaces content without scripted focus movement. No timed navigation or automatic modal opening appears in the reviewed script.
Next step: Verify live weather states and gallery interactions with assistive technology to distinguish content updates from unexpected context changes.
Evidence: Every template includes the same footer links to Accessibility and the official parks department. However, the website support email appears in different main-content positions on Sources and Accessibility. Repeated contact-help ordering needs a deliberate comparison in rendered reading order.
Next step: Compare repeated support contact placement and reading order, then standardize any inconsistent help mechanisms across the relevant pages.
Evidence: The visitor guide accepts no free-text entries or submitted forms. Its Display selector offers three fixed valid choices and has no input-validation errors. Weather-fetch failures are service status conditions, not errors in information supplied by the visitor.
Next step: Reassess this criterion if forms or any user-entered information with automatic validation are introduced.
Evidence: The Accessibility page associates the visible Display label with the reading-mode select and gives descriptive names to its three options. Nearby text explains the appearance changes and that preferences are stored only on the visitor's device.
Next step: Confirm the visible label, option names, and nearby instructions are understandable when read with assistive technology.
Evidence: No visitor input is automatically rejected or validated in the current guide. The fixed Display choices do not produce correctable input errors. The weather fallback directs visitors to the National Weather Service for an unavailable external data service.
Next step: Add actionable correction suggestions if future forms introduce detected input errors with known remedies.
Evidence: The guide does not process purchases, reservations, legal commitments, test responses, or changes to user records. Reservation links lead to external city services. Its only stored setting is a locally reversible display preference, with no personal-data submission.
Next step: Reassess before adding transactions, bookings, personal records, deletion controls, or any other consequential user submissions.
Evidence: The Display control has nearby explanatory text describing reading space, monochrome colors, browser alternatives, and local storage. The guide also offers visit FAQs and an accessibility support address. Context-sensitive assistance for the current limited input is present in the source.
Next step: Test whether visitors can understand and change display preferences using the adjacent help without additional explanation.
Evidence: No page requires visitors to submit information to this guide. The Display select changes local presentation and can be changed back immediately. Contact actions use email links, while reservations occur on separately maintained external city websites.
Next step: Review confirmation, correction, or reversal options before adding any form that requires visitor information to be submitted.
Evidence: The site has no multistep data-entry process, account creation, or reservation form. Visitors never need to re-enter previously supplied information. The single Display preference is stored locally and restored rather than repeatedly requested during browsing.
Next step: Reassess if future processes ask visitors for information across multiple steps or repeat earlier entries.
Evidence: All visitor-guide pages are publicly readable without accounts, login, passwords, or identity checks. Source review found no authentication interface or cognitive authentication test. External reservation and social services are linked destinations and are not part of this site implementation.
Next step: Audit authentication before introducing protected pages or accounts, including any third-party sign-in process integrated into this site.
Evidence: The current guide contains no authentication process, password recovery, recognition challenge, or personal-content verification. Browsing photos, changing display preferences, and reading weather information require no identity proof. Therefore no enhanced authentication interaction exists within the reviewed HTML scope.
Next step: Apply the enhanced authentication requirements to every step if accounts or any identity-verification workflow are added later.
Can browsers and assistive technologies interpret the content and controls?
4.1.2 Name, Role, Value
Level A · Needs manual review
Evidence: The source uses native buttons, links, select, details, and dialog elements. Gallery buttons have names, the dialog references its heading, and Display has an associated label. README records automated checks, but complete screen-reader verification of dynamic states remains outstanding.
Next step: Test names, roles, values, disclosure states, dialog announcements, and weather button state changes with supported browser and screen-reader combinations.
Evidence: Display confirmation and weather-check messages use role="status". Forecast and alert content is dynamically replaced, while weather failures receive explanatory text. No full screen-reader check establishes whether loading, completion, unavailability, and active-alert results are conveyed sufficiently without moving focus.
Next step: Exercise loading, success, failure, empty alerts, and active alerts with screen readers, verifying useful announcements without forced focus changes.
Test with screen readers. Confirm reading order, image text, landmarks, dialog focus and weather announcements using an appropriate browser and assistive-technology matrix.
Measure all visual states. Check enhanced text contrast, focus size and contrast, focus visibility, target dimensions, zoom, text spacing and forced colors across the site.
Review the language. Check reading level, unusual words, abbreviations and any pronunciation that affects meaning. Live weather alerts need special attention because their text can change.
Exercise all interaction states. Include long alerts, provider errors, expanded disclosures, every photo, every display preference and small landscape screens.
Review the report documents themselves. The PDF contains structural tags and real text, but its screen-reader behavior and PDF/UA conformance have not been verified. Reassess both report formats whenever they change.
What a conformance claim requires
Level AAA requires every applicable Level A, AA and AAA success criterion to be satisfied. A high automated score or a list of implemented features is not enough.
A claim must cover full pages and complete processes, rely on accessibility-supported uses of technology, and ensure that other content does not interfere with access. Third-party weather content displayed inside our pages is part of those pages.
If a formal claim is made later, it must identify its date, the WCAG version and level, the pages covered and the technologies relied upon. The W3C logo is a publisher claim; it does not mean that W3C reviewed or certified the site.
Email support@belltowerdigital.com with the page address and the problem. Browser and assistive technology details can help. Personal or medical information is not needed.
Words used in this report
WCAG means Web Content Accessibility Guidelines. A criterion is one requirement in the standard. Conformance means meeting every applicable requirement at the stated level. Assistive technology includes tools such as screen readers that help people use a computer. HTML is the format used to structure web pages. CSS controls their presentation. WAI-ARIA provides information about controls to assistive technologies. PDF is a portable document format, and PDF/UA is a standard for accessible PDF files.
