[Tracking issue] Feedback contributors at the contributor day WCEU'26

[rianrietveld]

This is a listing of all the feedback contributors gave at the contributor day WCEU'26 in Krakow.
Some we can combine in one PR, others may require a seperate issue first. This issue is just to collect the feedback and keep track of the changes we have to do. The order is ad random.

Łukasz Zygiel

Link to PDF in Slack: https://wordpress.slack.com/files/U02S2PJPC/F0B83CJKC83/wpaccessibility.org_quick_review_by_lukas_zygiel__newbie_wp_contributor_.pdf

• Won't fix Internal vs. external links—external should open in a new tab and be explicitly marked as external.
• Won't fix Links might be differentiated—what is linking to other parts of docs we are reading, and what is
  “additional sources” probably out of the website itself (extensive, additional)?
• Will fix: "blockquote" vs. “info-callout” divs differentiation—not sure what those elaborations should
  mean—are they marking different or similar things? (e.g.
  https://wpaccessibility.org/docs/topics/code/focus-handling/autofocus/) Adding a heading or bold
  text to the section will give context (and probably should be used consistently)
  Also, they are quite similar to “Notice Banner” component from WordPress – might be misleading
  a little.
• Will fix: Examples in DOs & DON’Ts section (especially code snippets) – might be visually separated
  (law of proximity or similar)
• Will fix: https://wpaccessibility.org/docs/topics/design/color/use-of-color/ For example, LINKS NOT WORKING (old url structure probably): = Page not found
• Will cross link: Error, success, or notification messages; more info in Write out an error message in text.
• Will cross link: Links in the content, more info in Styling links.
• Will cross link: Active, hover or focus states, more info in Styling focus and hover states of interactive
  HTML elements.
• We have that in the meta data with each topic: Display information updates.

General remarks:
[Note Rian: we will redesugn/resturcture the reading guide]
It seems some sections are loose collections of information on A11y and it might be helpful to
group/collect them in some “GOAL” or “USER GROUP”-oriented manner.
“Guidelines for the WordPress accessibility-ready tag” section seems to be well planned for the people
who aim to prepare fully accessible themes—and they guide you through the process to completion.

• Previous sections seem to be set for some rules, but it might be difficult to differentiate them, esp.
  for beginners. So some general rules for content: some of them are frontend-related (frontend
  dev?), and some are design. It would be beneficial to orient them according to those personas,
  maybe:
  i. Newbie – where to start – triage them (me ;) ) for fundamentals, then how-to aimed at
  specific cases (e.g., “you work with fronted → know this," "You design it → should
  always think this," "Create content and want to include all people? → Great, we’ve got
  you started here!” etc.
• WHYs
  So what I am trying to say is it would be good to structure the content in some strategic manner,
  maybe.
  i. Fundamentals for all – WHY A11Y at all.
  ii. Primer 101 for everybody with a WP mission to support all.
  iii. A11y in the context of regulations across the world – to understand regional differentiation
  and legal implications maybe (re: Legislation).
  iv. Accessibility Statement, ACRs—why to prepare.
• HOWs
  Then guidelines – more hands on, with “my” specific contexts for :
  i. Content creators (authors, editors)
  ii. Content designers: not sure if that is still the case with Guttneberg ;), so maybe part of the
  above? (content creators)?
  iii. Frontend (theme & plugin vs plugin only or general for devs) developers
  iv. Theme developers – already existing “Guidelines for the WordPress accessibility-ready
  tag” seem to target exactly that.
• Accessibility Statement, ACRs, etc. – how to prepare
  All with contextual tools links & resources for that context/specific usage/target group (if
  applicable, of course),

At the end (I know, what the hack), I saw the “Start with accessibility” section last : so my general
remarks might seem repetitive, as many things are similar in “Start with accessibility”, but I still think the
structure might be more tailored to this goal/user group approach (re: “Guidelines for the WordPress
accessibility-ready tag”). Not sure if this was my wandering mind or maybe lack of anchoring visuals on
landing (“Hey, designers! This way…”) that I landed there last.
So my last thought is I was actually looped in the content a little to much, so my thought is we could
structure it a little more across some paths/grid/matrix to make it more digestible and also actionable per
user type/needs.
So structuring the content (IA?) might be improved, especially landing page and some re/directing users
(triage of user type vs. needs vs goal on the site). But – maybe I’m biased and imposing my own
cognitive map on it? Not sure it helps, but that sums up my ~2h with the website.

ellakharris

Note (Joe): We'll work on fixing the search behavior, but we're not going to prioritize customizing the Wapuu. If somebody wishes to open a PR to add that cute change, feel free.
Might just be for me, but the little wapuu (correct name?) doesn't touch the bottom of the screen when you select search without anything written in the search bar. Probably a simple fix. Also i think it'd give the page some character if you made a variation (like the wave) of the wapuu looking sad, to go under the "No search term entered". (Or even just giving it a different expression on the no search result page. Not necessary but it'd ad something mildly delightful.)

nathanjamescockerill

https://wpaccessibility.org/docs/topics/code/semantics/ - iWatch might want to be replaced with Apple Watch (probably not that important 😅)

Julia Lissel

The documentation page for Link Text (https://wpaccessibility.org/docs/topics/content/links/link-text/) contains images that are currently missing alt attributes.

On this page https://wpaccessibility.org/docs/start/wcag-intro/ in section Section 5: Conformance, maybe add the full name of 5.2.5 in the link. 5.2.5 Non-Interference

https://wpaccessibility.org/docs/start/wcag-intro/ Section Implementing the guidelines.
Consider adding the name of the quick reference guide in the link as W3C quick reference guide.

https://wpaccessibility.org/docs/start/wcag-intro/

• Where: "Testing or getting tested" section.
• Current text: "More about testing"
• Consider changing to: "More about accessibility testing"

https://wpaccessibility.org/docs/start/training/discussion/

• Where: Slack channels
• Current text: A11y Slack account. A space to ask questions, help other people figure stuff out or chat about accessibility in general. Members can invite others.
• Consider: If users must have an invite to join, we should explicitly state: "Note: An invitation is required to join."

Monika

Broken link : Write out an error message in text - on this site: https://wpaccessibility.org/docs/topics/design/color/use-of-color/

Broken links: Styling links, Styling focus and hover states of interactive HTML elements

[amberhinds]

RE

Internal vs. external links—external should open in a new tab and be explicitly marked as external.

It is an accessibility best practice to give uses control over where links open. I would not want to default to all external links open in new windows even with a warning.

[joedolson]

@amberhinds Rian & and I also agree that we don't want to mark external links.