The discussion revolves around accessibility issues identified by Keros on a non-live site, focusing on problems like missing aria-labels, heading labels, and alt text for avatars. Niko_Taitano reports failures related to landmarks, headings, and native widgets, seeking guidance on how to report them effectively. sam advises providing specific, actionable feedback with reasons for each issue. Niko_Taitano follows up with examples, including missing headings on the profile page, unclear user icon labels, and lack of alt text for avatars. codinghorror requests more details, such as specific URLs and HTML elements, noting that automated tools may be unreliable for JavaScript-heavy sites like Discourse. Niko_Taitano clarifies that the site is not live, making information sharing limited, and provides code snippets and context for the issues. codinghorror warns that automated scanners often fail with dynamic JavaScript apps, as they expect static HTML, highlighting the complexity of accessibility testing in such environments.
Hello Discourse team,
We recently ran an automated Accessibility pass using Keros on our site, and had quite a few fail instances. A lot of the failures related to things like Landmarks not having unique roles (aria-label) or ARIA attributes not having valid values.
I was just wondering how I should go about reporting those kinds of issues here? Should I list a few examples for each section (like Landmarks, Headings, Native Widgets, etc.)? Any feedback would be greatly appreciated. Thanks!
Specific actionable feedback is the way to go here.
Eg:
Suggestion : add aria-label with XYZ to element ABC
Reason: Currently it is very hard to tell EFG cause of missing decorations etc.
And so on.
Start with the 3 most urgent changes.
Hello @sam
Thanks for the help! In that case, I’ll start with these items:
Suggestion: Add heading name to user Profile page.
Reason: Without a heading label, users with disabilities might not know what content is on the page, or they may have a hard time finding the information they need.
Suggestion: Add “avatar/icon” or “profile” to user icon titles (for example, when using a screenreader and hovering over a user’s Profile pic, it simply says their Gamertag).
Reason: It’s immediately decipherable from context that user icons will link to their Profile page when selected.
Suggestion: Add titles or labels to social media Footer links.
Reason: When using a screenreader and hovering over the social media links in the footer (YouTube, Facebook, Twitter, Instagram), it only says “Link” and is not specific enough.
Please review these items and let me know if you need more info or clarification.
Thanks!
These are unclear to me.
Can you specify what page you are talking about, and what HTML element on the page, maybe with some source code in your post?
Which URL are you referring to here? Every time an avatar appears on the page, or just the user profile page?
We have no footer at meta.discourse.org are you referring to some other website?
Hello Jeff,
Sorry about that, reporting issues here is new to me, and it’s kind of difficult because we aren’t allowed to share much information about the site since it isn’t live yet. But let me try to elaborate:
The page URLs that are listed are for the Profile page (Summary, Activity, Bookmarks, etc.). Here is the Code Snippet along with the fix suggestions:
Correct, every time an avatar is on a page. It’s not clear that an avatar is a link to a user’s profile page. <img alt="" width="32" height="32" src="[avatar image]" title="[Gamertag]" class="avatar">
Please ignore the footer issue, it’s custom and can be fixed by us. Apologies for that.
But I’d like to replace that with another issue, which is missing alt text from user Avatar images. It’s just simply blank:
<img alt="" width="32" height="32" src="[avatar image]" title="[Gamertag]" class="avatar">
If you are using automated scanners, be warned, these tools are particularly unreliable when used against JavaScript apps like Discourse – they expect “old school” websites where everything is served in HTML in the server HTTP request. Discourse serves JavaScript which programmatically builds each page on demand as the user clicks / taps on things.
