Our approach
We aim to use readable text, meaningful headings, keyboard-accessible navigation, descriptive image alternatives, visible focus, and responsive layouts. Accessibility is an ongoing process rather than a one-time certification.
Known limitations
Some older photos, documents, captions, or third-party content may not yet meet every accessibility need. A site owner should test the live pages with keyboard navigation, zoom, screen readers, and automated tools, then prioritize fixes.
Feedback and assistance
If you encounter a barrier, please contact the site operator with the page URL, the issue, and what you were trying to do. Use the contact page linked in the website navigation to report an accessibility barrier or request an alternate format. We will make reasonable efforts to respond and provide information in an accessible format.
Standards and review
Use applicable accessibility requirements and recognized guidance, such as WCAG, as a practical reference. Do not claim conformance or certification unless an appropriate audit supports that claim. Review this statement after significant site updates.
Effective date: October 20, 2026. This page was last updated October 20, 2026.
Accessible content writing
Editors should use plain language where it can communicate the same meaning, define unfamiliar terms, and avoid relying on visual placement alone to explain a page. Headings should describe the topic that follows. Link text should identify a destination or action, and adjacent links should not be indistinguishable when read out of context. Important instructions should appear before a form control that depends on them. Long community stories should be broken into meaningful sections so visitors can navigate by headings and understand the overall structure.
Keyboard interaction
All interactive controls should be reachable and usable with a keyboard. Focus should move in a predictable order, remain visible, and not be obscured by sticky headers or overlays. Menus should open and close through supported keyboard commands and should not require hover alone. A visitor should be able to escape a dialog or popover and return focus to the control that opened it. If a widget is supplied by a third party, its keyboard behavior should be checked before it is deployed on public pages.
Screen-reader semantics
HTML elements should communicate their roles and states to assistive technology. Buttons should be buttons, links should navigate, and form fields should have associated labels. Images should have appropriate alternative text or be marked decorative. Dynamic messages such as guestbook submission success or validation failure should be announced in a useful way. ARIA attributes should supplement correct native semantics rather than replace them unnecessarily. Testing should include reading order, heading navigation, landmark navigation, and the names of controls.
Reflow and magnification
Pages should remain functional when magnified and should avoid requiring horizontal scrolling for ordinary text at common narrow viewport widths, except for content that inherently needs two-dimensional presentation. Text should be resizable without loss of information or controls. Layout should tolerate increased line spacing, letter spacing, and word spacing. Fixed-height containers should not clip enlarged text. Visitors using browser zoom, magnification software, or mobile display settings should be able to read stories and reach the footer links without content disappearing.
Accessible photographs
When adding a photograph, editors should decide whether it conveys information or is purely decorative. Meaningful images need concise text alternatives that communicate the relevant scene or purpose without guessing identity or sensitive traits. Decorative images should use empty alternative text so they do not create noise. If an image contains important text, that text should also be available as real page text. Group photographs may need a caption describing the occasion or context, but should avoid naming people without permission or reliable identification.
Color and visual presentation
Contrast should be checked for normal text, large text, icons, form borders, and focus indicators. Color should not be the sole cue for links, errors, or status; wording, shape, or another visual indicator should also communicate meaning. Background photographs and gradients should not reduce text readability. The page should remain understandable when stylesheets are disabled or user colors override the design. Animation should be limited and respect reduced-motion preferences, and content should not flash in a way that risks triggering a seizure.
Forms and error prevention
Forms should explain the expected input format and identify mandatory fields. Labels should remain visible or programmatically available when a field receives focus. Validation should identify the affected field and describe the problem in text, not just by color. Where possible, entered data should remain after a correctable error. A guestbook should not depend exclusively on a visual CAPTCHA; accessible alternatives or a different spam-prevention design should be considered. Submission should produce a clear confirmation or error state that assistive technology can perceive.
Testing practices
Accessibility checks should combine automated scanning with manual review. Automated tools can catch missing labels, some contrast problems, and structural defects, but they cannot judge whether a photo description is useful or whether a workflow makes sense. Manual checks should include keyboard-only use, a screen reader, browser zoom, reflow, high contrast settings, reduced motion, and mobile layouts. Major changes to navigation, the guestbook, forms, or third-party widgets should trigger another review. Issues should be recorded, prioritized, and retested after correction.
Third-party limitations
Some externally embedded content may have accessibility barriers that the operator cannot directly fix. Where possible, provide an accessible link to the provider’s content, avoid loading an inaccessible embed as the only way to obtain information, and choose alternatives that better support keyboard and assistive technology. A third-party limitation should be described accurately rather than used as a blanket excuse. The operator may contact the provider or replace the integration if it prevents meaningful access to an important community feature.
Legal context and feedback
Accessibility requirements can arise under the ADA, California civil rights laws, and other state, federal, or international rules depending on the website and activity. WCAG is used as a design and testing reference, not a declaration of legal certification. Visitors who encounter a barrier may contact the operator through the published site contact method. Please include the page, the task you attempted, and the nature of the obstacle; sharing a diagnosis is not necessary. We will review reports and seek a reasonable response while preserving any rights available under applicable law.
Accessible content authoring
People who publish pages should use plain, descriptive language, define unfamiliar abbreviations, and break long material into sections with meaningful headings. Links should describe their destination rather than relying on “click here.” Images should receive useful alternative text based on the information they convey, and captions should not duplicate alt text unnecessarily. A heading should not be chosen only because its visual size looks right; document structure should reflect the content hierarchy. Tables should be used for genuinely tabular information and should include clear header relationships. These practices help screen-reader users, people with cognitive disabilities, visitors using translation tools, and anyone reading on a small screen or under difficult conditions.
Keyboard and focus behavior
Interactive controls should be reachable and usable with a keyboard, including the menu, guestbook fields, submit controls, and any dialog or cookie preference interface. The focus order should follow the visual and logical reading order. Focus must be visible, should not be hidden behind sticky headers or overlays, and should return to a sensible location after a dialog closes. Escape should close a dismissible dialog when that behavior is expected, and controls should not require dragging or complex pointer gestures without an alternative. Keyboard testing should include tab, shift-tab, enter, space, and arrow keys where the control pattern uses them. A decorative hover effect is not a substitute for a focus state.
Readable layouts and responsive behavior
The site should remain usable when a visitor enlarges text, increases line spacing, changes fonts, or uses browser zoom. Content should reflow without requiring horizontal scrolling for ordinary text at narrow viewport widths, except where a genuinely two-dimensional layout is necessary. Buttons and links should have enough space to activate without accidental neighboring selections. Page content should not disappear when scripts fail or when a visitor disables animation. The header and footer should not cover important information, and navigation should remain understandable when its responsive menu is expanded or collapsed. Testing should include mobile orientation, high zoom, and larger text settings rather than only the developer's default desktop view.
Accessible participation and moderation
The guestbook should make it clear which fields are optional, what information will be public, and how to submit a message. The submit control should have a descriptive accessible name and provide a visible and programmatically announced result. If a message fails, the page should identify the problem and allow the contributor to correct it without losing their text where feasible. Moderation notices should be written in neutral language and should not disclose private information. If an anti-spam tool creates an access barrier, the operator should consider a simpler alternative, such as a review queue or rate limit, rather than relying only on an inaccessible challenge. A participant should not need to disclose a disability to use a basic community feature.
Third-party accessibility
A linked service or embedded widget may not meet the same accessibility expectations as the site's own pages. When choosing a provider, the operator should review available accessibility documentation, test the actual integration, and avoid adding a widget that blocks keyboard navigation or screen-reader access. An accessibility overlay cannot automatically repair all underlying issues and should not be represented as a guarantee of compliance. If an embedded service is essential, provide an alternative route to the information or action where practical. If it is optional, consider a direct link or a user-activated load that avoids making the provider's interface part of every page visit.
Feedback handling and reasonable alternatives
When a visitor reports an access barrier, the operator should acknowledge the specific difficulty, avoid asking for medical details, and determine whether the issue can be corrected in the page or whether a temporary alternative is needed. An alternative should convey substantially the same information or permit the same basic task, rather than merely directing the visitor to start over elsewhere. For example, if a photograph's description is missing, the operator may provide a text description; if a form control cannot be reached, the operator may offer an accessible way to submit the same message while repairing the control. The response should explain any known limitation without blaming the visitor's device or assistive technology. Reports should be used to improve the website and should not be published with the reporter's name without permission.
Accessibility and privacy together
Accessibility support should be designed to avoid collecting unnecessary personal information. A visitor requesting a larger text format, a transcript, or help with a guestbook entry should not need to disclose a diagnosis, medical history, or disability documentation. If a temporary support request includes personal details, access to that communication should be limited and it should not be placed in a public page. The operator should retain the request only as long as needed to respond, document a fix, or meet a legal obligation. An accessibility preference stored in a browser should be limited to the setting itself and should not be used to infer a person's health status or create an advertising audience. These practices support both equal access and privacy.
Review after redesigns and uploads
A visual redesign, new logo, photo gallery, guestbook update, or cookie banner can change accessibility even when the content remains the same. Before publishing a substantial update, the operator should check heading order, image alternatives, keyboard focus, form labels, responsive behavior, and whether overlays obscure controls. A ZIP upload should not remove accessibility features or replace a working navigation script with an inaccessible version. Testing should include the live page after deployment, because server paths, caching, and production scripts can differ from a local preview. If a regression is found, the operator should prioritize restoring access to essential navigation and community participation while preparing a complete correction. Accessibility checks should be part of normal maintenance, not only a one-time launch checklist.