1161: Views Block Rework - #466
Open
dblanken-yale wants to merge 10 commits into
Open
Conversation
The post/event/page/profile card templates did not pass reference_card__heading_level, so reference-card defaulted the title to h3. When a listing block has no heading the component-wrapper renders no h2, so the cards followed the page h1 directly and skipped from h1 to h3 -- an axe heading-order (skipped heading level) violation QA flagged on the first event card of a listing. Pass reference_card__heading_level: '2' from the four listing card templates, matching node--view--taxonomy-term.html.twig. The level only sets the heading tag (visual size comes from BEM modifier classes, unchanged), so this fixes the outline without altering appearance: a headingless listing now renders h1 -> h2, and a listing with a block heading renders h2 -> h2 (flat, but not a skip). Refs #1161
Follow-up to hardcoding listing card headings at H2: the correct level depends on whether the listing block renders its own heading. Read the per-result node.card_heading_level stamped by ys_views_basic instead of a fixed level, so cards nest at H3 under a block heading and sit at H2 when the block has none. Each template keeps its prior default (card H2; list/condensed/directory H3) as the fallback for non-listing renders, which never set the property. Refs #1161
dblanken-yale
force-pushed
the
1318-views-rework
branch
from
June 22, 2026 17:38
d1968e4 to
c0ae956
Compare
26 tasks
Supports auto-running the scaffold listing filters (paired with the config change that enables Better Exposed Filters autosubmit on the scaffold views). - Add the WCAG 2.1 SC 3.2.2 advisory note to the exposed-filter form template so users are told up front that results update on their own, keeping the auto-submit from being an unexpected change of context. - Announce the updated result count to assistive technology after each filter update via Drupal.announce (SC 4.1.3), skipping the initial page render. atomic_preprocess_views_view() passes the count per view DOM id; a small behavior reads it and announces on filter-driven updates only. References yalesites-org/YaleSites-Internal#1367
The visible "Results update automatically as you make selections." note is no longer wanted (QA): auto-submit is already conveyed to assistive tech by the polite aria-live result-count announcement (views-basic-filter-status.js), so the persistent visible note is redundant. Remove it from the scaffold exposed form; the screen-reader announcement stays. Refs #1367
Core's Views AJAX adds a ScrollTopCommand whenever the request carries a pager_element, which the Views AJAX settings always include — so the scroll-to-top fired on every exposed-filter auto-submit, not just pager clicks, yanking the page down while typing in a listing filter (#1299 QA). Add a small theme behavior that wraps the `scrollTop` AJAX command and skips it only when the request came from a listing exposed-filter form (identified by the form's data-drupal-target-view dom id being a key in the existing ysViewsBasicFilter registry). Pagers and every other caller keep the default scroll. Attached only for the scaffold listing views. Refs #1299
dblanken-yale
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
1161: Views Block Architectural Rework
Companion theme PR addressing a QA accessibility finding on the views/listing block rework (yalesites-org/yalesites-project#1299).
Description of work
Set the listing card heading level to
h2in the post, event, page, and profilecardview-mode templates (reference_card__heading_level: '2'), matching the existingnode--view--taxonomy-term.html.twigpattern.Fixes the axe
heading-order(skipped heading level) violation QA flagged on the first card of a listing: when a listing block has no heading, the component-wrapper renders noh2, so the cards previously followed the pageh1directly and jumped toh3. The level only changes the heading tag — visual size comes from BEM modifier classes, so appearance is unchanged.Other work completed in: 1161: Views rework yalesites-project#1299, 1161: Views Block Rework component-library-twig#649
Functional testing steps:
h2directly under the pageh1(no skipped level in axe).h2(block) thenh2(cards) with no skipped level.References yalesites-org/YaleSites-Internal#1161