问题 1：损坏的标题导航 / DOM 操作

[adress (Angela Dresselhaus)]

Issue: Reply post elements are not initially shown on the Document Object Model (DOM) at initial page load, and are removed from the DOM after the screen reader has passed them, causing Windows screen readers to lose access to content and VoiceOver to be limited in the tools that can be used to access the page.

Specific Behavior:

● When attempting to navigate from the main post to reply posts, elements used in the reply posts have not yet been rendered on the DOM, therefore users cannot use quick navigation to navigate to any element in any reply post.

● Individual reply posts are marked as heading level 2 in the DOM only when the screen reader is focused on them, requiring users to navigate every element on the page in order to reach reply posts.

● ANDI accessibility tool shows a constantly changing heading structure after element interactions.

● Elements show “removed from the DOM” errors when attempting to access them

● Screen reader loses consistent view of page structure

Platform Details:

● JAWS/NVDA: Complete failure - cannot access reply headings at all

● VoiceOver: Access via quick navigation but no rotor access - because VoiceOver works by reading the direct page, users can navigate reply headings using quick navigation keys, however only elements the screen reader is focused on are accessible within the rotor.

Why Critical: Screen reader users cannot complete the key task of reading discussion replies. This is a total barrier to participating in discussions.

[adress (Angela Dresselhaus)]

These issues were first reported in Screen Reader Accessibility issues . Please assist in resolving, we have an entire community of blind and low vision users unable to complete basic functions on the discussion board.

[awesomerobot (Kris)]

Thanks for reporting these!

Do you know which topic(s) this was tested on specifically? It would be helpful to have a shared reference for this to make sure we’re seeing the same issues, there are a lot of variations with post content so I’d like to make sure we’re focusing our efforts in the correct place.

We could use try.discourse.org, or we can use a post here on Meta for reference if that would help.

@adress

therefore users cannot use quick navigation to navigate to any element in any reply post.

By “quick navigation” it seems you’re reporting element lists specifically? I can confirm that both in NVDA and VoiceOver that only the content currently available in the DOM can be accessed in element lists, this is also true for sighted users and it’s a fundamental part of how Discourse works. In lieu of manual pagination, we load/offload content as someone scrolls down/up the page.

@adress

requiring users to navigate every element on the page in order to reach reply posts.

This is usually what I expect when someone mentions “quick navigation” though I realize there’s not always consistent terminology across applications.

I’ve confirmed element to element navigation works in NVDA and VoiceOver, but I have identified an issue with our “small posts” within topics that can prevent navigation from continuing and will apply a fix for it.

A “small post” is a topic status update like pinned, closed/opened, actived, etc. The issue with these is that they don’t have an internal heading like regular posts, so when they fall on the threshold before more posts would be loaded while navigating… a user may be stopped and only hear “no next heading.”

@adress

ANDI accessibility tool shows a constantly changing heading structure after element interactions.

Automated tools like ANDI often fail to recognize DOM changes in web applications like Discourse, they’re generally built for simpler scenarios like static pages. So while we’ll sometimes use these tools to identify issues ourselves, in more complex scenarios like navigation we have to focus on what we can reproduce with manual testing.

@adress

Elements show “removed from the DOM” errors when attempting to access them

Screen reader loses consistent view of page structure

I assume this too is in reference to element lists? this is expected, but perhaps there’s an enhancement we can consider to make element lists work in Discourse, I can take this up with our engineers for input.

@adress

JAWS/NVDA: Complete failure - cannot access reply headings at all

Is this also specifically in an elements list? As mentioned above I’ve tested NVDA and VoiceOver navigation for element-to-element navigation, and can confirm this works… but if there’s a specific context it doesn’t work in we can take a closer look.

[adress (Angela Dresselhaus)]

@awesomerobot

Do you know which topic(s) this was tested on specifically?

Latest Expanded Core Curriculum/Mastering the Monarch topics - APH Hive Discussion Board

The express activities were tested.

[awesomerobot (Kris)]

Quick update on this, I’ve been working on improving our landmarks in a way that should provide a better way to navigate an element list.

Navigating headings in element lists will remain unchanged, but hopefully this provides a reasonable alternative. Changes are outlined here: A11Y: improve landmark navigation and add aria-labels to post controls by awesomerobot · Pull Request #34421 · discourse/discourse · GitHub

In short, what this does is:

• Provide landmark regions for all posts in the DOM

• Adds a landmark region that makes it clearer there are more posts above/below — we load/unload posts so we don’t have to use manual pagination, if a topic had hundreds of posts loaded into the DOM at once it could cause performance issues.

  Making all of the heading content accessible in the DOM without degrading performance for everyone would be a very complicated change, so this is a bit of a middle-ground. While not perfect, navigating to the “load more content” areas will properly load more posts, at which point the element list can be reopened.

• I’ve made an update to change the post controls from a navigation region to a toolbar region, this is more semantically accurate and allows the landmark region list to focus on posts.

• I’ve also improved labeling on the post controls while I was at it

So we’re going from a rather sparse landmark element list within topics

To something that more clearly represents the topic structure

This update should land at some point this week. I’ll be curious to hear some feedback about these changes once they’re available @adress!

[Cody_Laplante]

Hi @awesomerobot we’ve been hired by APH for accessibility consultation on this issue. I’ve provided a couple of video links below showing our primary problem related to this thread. You’ll see the problem in the first recording beginning at timestamp 08:36 in the first recording.
Discourse Accessibility Audit JAWS
This is not related to the elements list but what we’d call Quick Keys or Quick Navigation in which we’ll navigate to the next html element type (in this case headings).

The problem with fixing this issue by creating new landmarks is that landmarks are typically reserved for high level sections, so to a screen reader user, navigating between small sections of the page with landmarks would take away quick access to the large regions of the page like the navigation banner. This also is in violation of WCAG standards level A creating a Bypass Block.

[awesomerobot (Kris)]

great, thanks for the additional details! a video will help tremendously - it appears the video is password protected, can you either unlock it or send the code to accessibility@discourse.org

[Cody_Laplante]

Yes sorry about that. Here is the link with embedded passcode. Video Conferencing, Web Conferencing, Webinars, Screen Sharing - Zoom
Passcode: .kBwdK3a

[dkapoor (Dylan Kapoor)]

Hey @awesomerobot, I’m a colleague of Cody’s and an accessibility engineer. I gave the repository a look to diagnose the issue. As you may already know, the core issue appears to be that (1) Content in cloaked posts are not viewable by screen readers and (2) Posts are only uncloaked when within a users view per PostStreamViewportTracker

Thinking through a potential fix, I want to optimize on two things: (1) Enable navigation of each post by heading with screen readers and (2) Minimize changes to the Discourse repo and impact on performance.

The approach I recommend is to keep a lightweight wrapper for each loaded post that includes the semantic H2 used for heading navigation, while the heavy post body remains cloaked. This keeps headings stable for assistive tech without inflating the DOM across the entire page. When a user lands on any post’s H2 via heading navigation, the screen reader will trigger a page scroll which will in turn uncloak the post’s body in place.

The viability of this solution depends on when the next chunk of posts are loaded. An optional improvement is a screen-reader only sentinel heading “load more posts” (similar to the "load more region” proposed in your PR) located at the bottom of the list of loaded posts. When this heading comes into view or is selected from the headings rotor, it loads the next chunk and announces completion via an aria-live=polite message.