GatherPress/gatherpress

Follow-up to the review on #2064. "Is this comment an RSVP" is spelled out by hand in a dozen places, each a slightly different shape: some compare $comment->comment_type, some call get_comment_type( $id ), Token did both. #2064 adds Rsvp::is_rsvp( int|WP_Comment $comment ): bool and uses it in Check_In and Token. The remaining sites should call it too, so there is one definition of the check. Sites on develop as of today: includes/core/classes/blocks/class-rsvp-form.php:708 includes/core/classes/blocks/class-rsvp-response.php:293 includes/core/classes/rsvp/class-form.php:252 includes/core/classes/rsvp/class-form.php:304 includes/core/classes/rsvp/class-form.php:597 includes/core/classes/rsvp/class-query.php:331 includes/core/classes/rsvp/class-query.php:406 includes/core/classes/rsvp/class-setup.php:506 includes/core/classes/rsvp/class-setup.php:639 includes/core/classes/rsvp/class-storage.php:250 Not in scope: class-query.php:286 and :305 compare a query var, not a comment, and cla

We use several words for the people who interact with a GatherPress site, and they have drifted. "Visitor" and "viewer" are used interchangeably for the same concept, and "reader" has started appearing in new code where it collides with the word we use for assistive technology everywhere else. This issue is to write down the rules and bring existing copy in line. Proposed rules viewer — anyone looking at a page. The general term, logged in or not. This is already how the codebase uses it internally (Event::is_viewable(), "the current viewer may read an event's RSVP responses"), and it is the right default because it makes no claim about whether someone has an account. visitor — only where "without an account" is the actual meaning. Not a synonym for viewer. If a string is about Open RSVP, logged-out fallbacks, or anything else where the absence of an account is the point, either keep "visitor" or say "people without an account" outright. attendee — someone who RSVP'd. Already con

Describe the bug Three small, independent accessibility gaps in the block editor UI. Grouping them because each is a few lines; they can be fixed together or one at a time. 1. Help text isn't associated with its control. src/components/GuestLimit.js:76 and src/components/MaxAttendanceLimit.js:79 render their descriptions as a sibling <p className="description">. Because nothing links the text to the input, a screen reader never reads it when the field takes focus. WordPress's own components accept a help prop that renders the same text and wires up aria-describedby — and the checkbox controls right next to these already use it, so the fix is switching to the prop the surrounding code already uses. 2. Focus outlines are removed. src/components/PatternPicker/index.scss:35 and src/blocks/venue-detail/editor.scss:55,63 set outline: none. In PatternPicker the replacement focus style is identical to the hover style (border colour only); on the venue address textarea the outline is removed

Describe the bug Several links open in a new tab without telling anyone first. Screen-reader users get no warning before their context changes, and sighted keyboard users lose their place with no explanation — the browser back button no longer returns them where they expect. Confirmed on develop: Online event link — src/blocks/online-event-link/render.php:64 (and the runtime swap in view.js:69) Add to calendar → Google Calendar and Yahoo Calendar — src/blocks/add-to-calendar/template.js Venue website links, where the author has set the link to open in a new tab A couple of editor-side links (event-date/edit.js:374, form-field/edit.js:356) The usual fix is a visually hidden note inside the link, so screen readers announce it and sighted users see no change: <a href="…" target="_blank" rel="noopener noreferrer"> Google Calendar<span class="screen-reader-text"> (opens in a new tab)</span> </a> WordPress core does this throughout the admin, so there's plenty of precedent to

Describe the bug Three hardcoded colors fail WCAG 2.2 SC 1.4.3 (Contrast Minimum, AA — 4.5:1 for normal-size text). Verified on current develop: Location Element Colors Ratio Verify includes/templates/admin/emails/event-email.php:90 "RSVP Now" button white on #007bff 3.98:1 WebAIM includes/templates/admin/emails/rsvp-token-confirmation.php:55 "Confirm My RSVP" button white on #3498db 3.15:1 WebAIM src/blocks/rsvp-form/templates/standard-rsvp-form.js:38 "Thank you for your RSVP!" heading #16a085 on white 3.28:1 WebAIM None of the three qualifies for WCAG's relaxed 3:1 large-text threshold, so 4.5:1 applies throughout: Both email buttons are font-weight: bold with no declared font-size anywhere in their templates — they inherit the email client's default body size (16px in mainstream clients), and 16px bold is below the 18.66px bold large-text cutoff. (Relying on client-default sizing is itself fragile; declaring an explicit font-size on the buttons could ride along wi