Probleem 1: Kapotte navigatie van koppen / DOM-manipulatie

[adress (Angela Dresselhaus)]

Probleem: Elementen van antwoorden worden bij het eerste laden van de pagina niet initieel weergegeven in de Document Object Model (DOM) en worden uit de DOM verwijderd nadat de schermlezer ze is gepasseerd, waardoor Windows-schermlezers de toegang tot inhoud verliezen en VoiceOver beperkt wordt in de tools die kunnen worden gebruikt om de pagina te openen.

Specifiek Gedrag:

● Bij het proberen te navigeren van het hoofdbericht naar antwoordberichten zijn elementen die in de antwoordberichten worden gebruikt nog niet in de DOM gerenderd, waardoor gebruikers geen snelle navigatie kunnen gebruiken om naar een element in een antwoordbericht te navigeren.

● Individuele antwoordberichten worden pas als kopniveau 2 in de DOM gemarkeerd wanneer de schermlezer erop gericht is, waardoor gebruikers elk element op de pagina moeten doorlopen om antwoordberichten te bereiken.

● De ANDI-toegankelijkheidstool toont een constant veranderende kopstructuur na interacties met elementen.

● Elementen tonen fouten zoals “uit de DOM verwijderd” bij het proberen er toegang toe te krijgen.

● Schermlezer verliest consistente weergave van paginastructuur.

Platformdetails:

● JAWS/NVDA: Volledige storing - helemaal geen toegang tot antwoordkoppen.

● VoiceOver: Toegang via snelle navigatie, maar geen rotor-toegang - omdat VoiceOver werkt door de directe pagina te lezen, kunnen gebruikers antwoordkoppen navigeren met snelle navigatietoetsen, maar alleen elementen waarop de schermlezer gericht is, zijn toegankelijk binnen de rotor.

Waarom Kritiek: Gebruikers van schermlezers kunnen de kerntaak van het lezen van discussieantwoorden niet voltooien. Dit is een totale barrière voor deelname aan discussies.

[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)]

Geweldig, bedankt voor de aanvullende details! Een video zal enorm helpen - het lijkt erop dat de video wachtwoordbeveiligd is, kun je deze ontgrendelen of de code sturen naar 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)]

Hallo @awesomerobot, ik ben een collega van Cody en een toegankelijkheidstechnicus. Ik heb de repository bekeken om het probleem te diagnosticeren. Zoals je misschien al weet, lijkt het kernprobleem te zijn dat (1) inhoud in gecamoufleerde berichten niet zichtbaar is voor schermlezers en (2) berichten pas worden ontcamoufleerd wanneer ze binnen het zicht van een gebruiker vallen per PostStreamViewportTracker.

Bij het nadenken over een mogelijke oplossing, wil ik me richten op twee dingen: (1) het mogelijk maken om elk bericht met schermlezers per kop te navigeren en (2) wijzigingen in de Discourse-repository en de impact op de prestaties te minimaliseren.

De aanpak die ik aanbeveel, is om een lichtgewicht wrapper te behouden voor elk geladen bericht dat de semantische H2 bevat die wordt gebruikt voor kopnavigatie, terwijl de zware berichttekst gecamoufleerd blijft. Dit houdt koppen stabiel voor ondersteunende technologie zonder de DOM over de hele pagina op te blazen. Wanneer een gebruiker via kopnavigatie op de H2 van een bericht terechtkomt, zal de schermlezer een paginascoroll activeren, die op zijn beurt de berichttekst op zijn plaats ontcamoufleert.

De haalbaarheid van deze oplossing hangt af van wanneer het volgende deel van de berichten wordt geladen. Een optionele verbetering is een alleen-voor-schermlezers sentinel-kop “meer berichten laden” (vergelijkbaar met de “meer regio laden” voorgesteld in je PR) onderaan de lijst met geladen berichten. Wanneer deze kop in beeld komt of wordt geselecteerd uit de koprotator, wordt het volgende deel geladen en wordt de voltooiing aangekondigd via een aria-live=polite bericht.

[awesomerobot (Kris)]

Bedankt voor de feedback en suggesties, we zullen dit intern bespreken en met een update komen!

[awesomerobot (Kris)]

@dkapoor

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.

This is the approach we’re currently working on in WIP: A11Y improve heading-to-heading nav, fix infinite scrolling by awesomerobot · Pull Request #34589 · discourse/discourse · GitHub

As you suggested, we’re adding some light screenreader-only headings on all posts (cloaked or not) as well as a heading that will trigger more posts loading, along with the announcement that loading is complete.

It’s still a work-in-progress, so it will still need some refinement, but hopefully we can get this fix available for everyone soon.

[awesomerobot (Kris)]

Snelle update over tijdlijnverwachtingen: we zitten de komende week in een pre-release freeze en een groot deel van ons team zal aanwezig zijn op onze jaarlijkse bijeenkomst… dus het zal waarschijnlijk een paar weken duren voordat deze wijziging kan worden doorgevoerd.

[awesomerobot (Kris)]

Hello! as of November 5th we’ve merged an update that is expected to improve topic navigation by heading. Some more details here:

@awesomerobot

Thanks for reporting this. As of yesterday we’ve merged an update that is intended to make post navigation via heading more reliable. We’ve ensured consistent headings are available for every post, and have added headings with live regions that will announce when additional posts are being loaded.