Content IA and Accessibility: decide how single VAMC + Outreach events should be treated

[kmariepat-cityfriends]

Background

• Get guidance from IA - 1 or n pages?

How many FE pages should get created for Events published to more than one Event List & how should breadcrumbs be handled?

Option 1 - Multiple Pages (one per listing page appearance)

RULED OUT.

• When an Event is added to multiple Event Lists, a unique HTML page is generated for each list
  • va.gov/chicago-health-care/events/#####/
  • va.gov/outreach-and-events/events/#####/
• Pro: Each page can have breadcrumbs specific to the list that users were browsing when they found the event
• Con: The number of page objects created increases and thus the time to build the site increases
• Con: SEO of duplicative pages. Which one should be set in canonical?
• Con: A11y requires unique Titles per page. Two pages with identical Title is bad.

Option 2 - Single Page, multiple paths

• When an Event is added to multiple Event Lists, a single HTML page is generated and all other lists just have URL aliases that point to the original
  • va.gov/chicago-health-care/events/#####/ (canonical)
  • va.gov/outreach-and-events/events/#####/ (URL alias)
• Con?: How does Drupal know which one to treat as canonical? Might need an additional interface component for editors to select. Or some kind of code to cross-reference the event location and the event list? The links would be built correctly.
• Con: Only one set of breadcrumbs for the event, confusing user experience when coming from non-canonical event list.
• If there is a way to have multiple breadcrumbs would be fragile based on browser history
  • Note that there may be a solution to this issue. When we were dealing with the Lovell leadership list there was a similar issue with a Staff profile being referenced on multiple leadership lists. But Lovell is so unique, this may not be relevant <- not quite the same issue or cause. The solution is likely that the default html of the page would give VAMC system, BUT if the referer was another event list JS would alter the breadcrumbs.
• Pro: The number of page objects created stays the same

Option 2A - Single Page, single path

• When a VAMC Event is added to the Outreach Event List, a single HTML page is generated and uses the canonical VAMC URL (e.g. va.gov/chicago-health-care/events/#####). Breadcrumbs will always point to the VAMC Events page, even if user has arrived at the Event page via the Outreach Events listing.
• Pro: The number of page objects created stays the same
• Pro: We avoid fragile breadcrumb solutions. A11y has signed off on the UX.
• Con: Only one set of breadcrumbs for the event, confusing user experience when coming from Outreach Events list.
  • If there is a way to have multiple breadcrumbs would be fragile based on browser history
  • Note: Same Lovell note as Option 2.
• Con: Lovell is confused and needs add'l work to resolve, WIP.
• Con: This will not work in the multi-VAMC / multi-Facility use case, when we get there. We will need to revisit breadcrumbs / paths, when multi-select is available.

Option 3 - Single Page all in Outreach Events, always

All event pages get built at va.gov/outreach-and-events/events/#####/ regardless of what listing page(s) they appear on. Breadcrumbs are either:

• Dynamic based on referrer.
• No breadcrumbs, just uses link that goes back one in the browser history.

• Pro: Each page can have breadcrumbs specific to the list that users were browsing when they found the event
• Pro: Veterans would get a decent experience and would be able to get back to wherever they were.
• Pro: The number of page objects created stays the same
• Con: Users may not grok how they landed in Outreach Events (a11y)
• Con: Additional complexity would make this impossible to deliver by 2023 Veterans Day goal, we think.

Option 4

• Have an event page and that page is grabbing data dynamically; link query parameters
• CON: no live API, build every event via KISS (every event becomes a JSON file)

How long should we keep Events published after they have ended?

• Automatically archive past events after X months #8231
• "By archiving 1000 events that were older than 6 months, the content release sped up by five minutes"

Open Questions:

• Behavior on the front end
• technical implementation (content build times) - Low concern
• How are we defining when event search is a problem data wise (page objects created might go up, node limits...) (take to CMS collab cycle) -- not necessary for single page solutions
• establish firm guidance on how long events stay published for -- not wrapped up in current effort, already has its own epic for future prioritization: Automatically archive past events after X months #8231

ACs

• Determine our proposal for smartest path forward
• Design review of proposal
• A11y review
• Initiate IA intake to review the proposal

[kmariepat-cityfriends]

@davidmpickett for a first pass draft of writing out option 1 and 2 referenced above

[swirtSJW]

I added a third option to kick around.

[kmariepat-cityfriends]

Context notes:

• public websites (PW) owns events; but this is a facilities driven use case. All editors are from a facility
• does it make sense for PW to own events

[kmariepat-cityfriends]

Context notes:

• public websites (PW) owns events; but this is a facilities driven use case. All editors are from a facility
• does it make sense for PW to own events

[mmiddaugh]

@jilladams is this still valid? If so, should it belong to Facilities or Public Websites?

[jilladams]

Chatted with Facilities re: SME for the previous conversations. Couple notes from that:

1. We will need to take this to CAIA, going to file an intake ticket with them to get it on the radar, but we need to settle on our proposal before they engage.
2. Michelle flagged: Breadcrumbs have inconsistent behavior (News releases, stories, events) between Listings & Single pages. This is known problem for Mikki, and she may be inclined to evaluate the bigger picture when we discuss. We'll need to manage expectations / scope there.
3. Dave Pickett is happy to discuss philosophically if needed, and Steve helped put together the proposals in ticket body, so @dsasser feel free to reach out to either or both if it would help think through things.

[jilladams]

Bigger picture on breadcrumbs history:
Standardize Breadcrumbs for events, news releases and stories #10030
[DISCOVERY] Intended breadcrumb behavior (VAMC)#13902

[jilladams]

@laflannery hi, FYI: We need to pull you in here. Context:

Daniel / Christia have a CMS solution working to add a checkbox to the Events form, that allows an Editor to select an Event listing from the dropdown, and select a checkbox to publish that same event to the Outreach events calendar. DaveC would like this to ship in time for Veterans Day if at all possible, but we have hit breadcrumb/URL issues that need your input.

Currently in the implementation:

• The Event will always create a URL based on the single selection within the Event Listing dropdown.
  • Breadcrumbs for Events are built from the Event URL.
  • If event is published to the Outreach Events listing in the dropdown, it will have Outreach URL / crumbs.
  • If the event is published to a VAMC listing (even if the National checkbox is checked): it will have a VAMC URL and breadcrumbs
    • Where a VAMC event is promoted to Outreach Events, the OE listing will point the user to the Event at the VAMC URL with VAMC breadcrumbs.
    • Lovell is currently borked. :D WIP.

Our team needs to:

• Unbreak Lovell
• Finalize a proposal for how this should work, re: URLs / breadcrumbs, and take that to CAIA for IA signoff. To do this, we'd like your A11y input to make sure we are having good ideas. I'm going to find time asap for a meeting.

Where to see this in action:
Tugboat: https://tugboat.vfs.va.gov/651ddd6e2d3036648dec2077
CMS: https://cms-thu3raipnqtrntaczkhou6vtskp73ajc.demo.cms.va.gov/
FE - Alaska VAMC event (Fri Oct. 6): https://web-thu3raipnqtrntaczkhou6vtskp73ajc.demo.cms.va.gov/alaska-health-care/events/
FE - Lovell event (Sat Oct 7): VA.gov URL: https://web-thu3raipnqtrntaczkhou6vtskp73ajc.demo.cms.va.gov/lovell-federal-health-care/events/61946
FE - Outreach events cal: https://web-thu3raipnqtrntaczkhou6vtskp73ajc.demo.cms.va.gov/outreach-and-events/events/

[jilladams]

(I just requested a content build on that tugboat, so may be ~30-45mins before FE is available again.)

[jilladams]

Laura's a11y notes:

• Single set of VAMC breadcrumbs isn't a nonstarter.
  • Breadcrumbs are labeled properly, and are clear about hierarchy. Users will get an expected result.
• Users can use back button (*if you're on page 2 and go to an event, then page back, you're sent to page 1 of the listings, out of scope for this situation to fix)
• Multiple pages with same title but 2 URLs (& different breadcrumbs), Option 1 above, raises a11y concerns from WCAG. Must have unique titles. (Also an SEO concern)

[wesrowe]

CAIA intake ticket to review our proposed breadcrumbs.

[jilladams]

@dsasser Updated ticket body to record what is happening today in the implementation in progress, as Option 2A. When you have a chance, give that a onceover, and confirm it's correct?

[dsasser]

@dsasser Updated ticket body to record what is happening today in the implementation in progress, as Option 2A. When you have a chance, give that a onceover, and confirm it's correct?

2A looks correct, thanks for adding that.

[laflannery]

@jilladams I had a thought early this morning and the tugboat isn't loading so I can't check the behavior - what happens to the "See all events" links at the bottom of the event pages? Do those follow the breadcrumbs? For example if I'm on the Outreach listing, then go to the Alaska event from above with the VAMC breadcrumbs and click on "See all events" does that take me to the VAMC events listing? I don't think my conclusion is going to change but I just want to be sure I know what's going to happen here.

[dsasser]

@laflannery

what happens to the "See all events" links at the bottom of the event pages? Do those follow the breadcrumbs?

The 'see more events' link does in fact follow the breadcrumb. This can be seen from the code snippet below, which uses the breadcrumb to build the link:

        <a
          class="vads-u-padding-bottom--3 vads-u-margin-top--1 vads-u-font-weight--bold"
          href="{{ entityUrl.breadcrumb | getValueFromArrayObjPath: index, 'url.path' }}"
          onclick="recordEvent({ event: 'nav-secondary-button-click' });">
          See more events

[laflannery]

Thanks @dsasser! I'm still good with everything just wanted to make sure

[dsasser]

Update

Without making any FE changes, the breadcrumb functionality aligns with option 2A

Option 2A

Option 2A - Single Page, single path When a VAMC Event is added to the Outreach Event List, a single HTML page is generated and uses the canonical VAMC URL (e.g. va.gov/chicago-health-care/events/#####). Breadcrumbs will always point to the VAMC Events page, even if user has arrived at the Event page via the Outreach Events listing. Pro: The number of page objects created stays the same Pro: We avoid fragile breadcrumb solutions. A11y has signed off on the UX. Con: Only one set of breadcrumbs for the event, confusing user experience when coming from Outreach Events list. If there is a way to have multiple breadcrumbs would be fragile based on browser history Note: Same Lovell note as Option 2. ~~Con: Lovell is confused and needs add'l work to resolve, WIP~~ (resolved by setting the 'Section' to the appropriate facility. Tests were previously using arbitrary sections) Con: This will not work in the multi-VAMC / multi-Facility use case, when we get there. We will need to revisit breadcrumbs / paths, when multi-select is available.

We have support from Laura in regards to a11y. So with that, we are ready to take this to CAIA and pending that approval, proceeding to change management.

[jilladams]

@dsasser CAIA intake is filed: department-of-veterans-affairs/va.gov-team#67025, and I created #15627 to track any follow up required from that discussion (it'll need to get refined once we've talked to CAIA). I vote this can close. Doing so.