Accessibility concerns re email, Lynx, JAWS

Feature
1

I’m considering migrating a large forum of around 2000 people from FB to Discourse. Some of my users are visually impaired.

What is the recommended way for visually impaired people to use Discourse?

I understand Lynx is read-only, so that won’t work. I’ve also done some searching and seen that JAWS has only partial support.

I do know that Discourse supports a lot of email integration. As of now, is it possible for a user to use Discourse entirely through email, getting all of the threads and replies in their inbox sorted properly, and being able to reply back, without having to use the site at all?

All of the searching I’ve done on this topic has found answers from a few years ago, so I’m not sure what the current state of this is.

4 Likes
2

Do you mean for Discourse period? We’ve done some work in the past to make it more usable by screen readers and I’d love to continue working through any issues we have for users with disabilities.

5 Likes
3

Discourse supports email notifications and replies via email. Threading can be a bit tricky depending on your mail client (some do a better job of collapsing into conversation view than others).

To enable mailing list mode, a user should modified these preferences on their account:

As an admin, you can also choose to make enabling these the default for new users:

2 Likes
4

@eviltrout, @wesochuck - thanks for the replies. I understand better how email works now.

I see that Lynx is read-only and doesn’t let you post. This would lock a lot of my users out of the site. This is probably the single hurdle stopping me from adopting Discourse.

Is there a workaround for that?

5

Sorry, but Discourse may not be a good fit for your community then. It is a javascript heavy application that the founders have built for “the next 10 years of the Internet”.

Also see: What is Discourse? | Discourse - Civilized Discussion

6

OK, makes sense. Thanks. FWIW, Lynx might still be around in 10 years, just because it’s so useful for the visually impaired. But who knows?

1 Like
7

As someone who habitually browses with JavaScript disabled (not due to visual impairment, I simply don’t like the idea of running arbitrary code from random sites willy-nilly), I have my doubts that lynx, as it exists today, is going to be much use 10 years from now as a browser for the general-purpose web. Already, a depressing percentage of sites display no content without JavaScript enabled, and I can only imagine that that percentage will increase over time.

1 Like
8

I hope this vision does not include “getting rid of” all visually impaired people ;).

Seriously though, Discourse should be a great choice for visually impaired, i.e. provide great accessibility – that also means it’s more compatible with alternative input methods (including voice) for anyone. Plus, it would be nice to cut back on some JS for simple reading and poking around, that’ll make Discourse even more accessible and also machine readable and thus crawlable by search engines (and no, SEs do not support JavaScript very well); e.g. make direct links to render on the server (i.e. render first visit on the server) instead of pushing all content including routing to the client and let it figure everything out by itself. This will also make Discourse faster (at least perceived speed, which is the most important measurement even if subjective).

See also the general discussion on JavaScript performance.

1 Like
9

The answer to making sites more accessible is not to make them work in Lynx and other text based browsers. It’s to embrace standards like ARIA which has the backing of all major browsers.

Right now, Discourse should work out of the box with a screen reader due to already using these standards. I’m sure we could be better, but improving that is going to require feedback from users who use the screen reading software and provide feedback. If something is preventing them from doing it I’d love to hear it :smile:

7 Likes
10

[Whoops, premature “Send”, will keep this post for historical reasons since @eviltrout already answered on this one – see my actual post.]

To be clear, I did not mean to say that making a site accessible requires it to be accessible with text based browsers, strong ARIA support is (als you already said). However, accessibility is more than being nice to screen readers, it is being nice to any (sensible) form

1 Like
11

I disagree. Being “nice to lynx” is not about accessibility, it’s about supporting obscure browsers. I would not lump “Netscape 4 support on Windows 95” under accessibility either.

Let’s focus on the users with disabilities (be they minor or major) and how we can help them use Discourse with the software they use every day like screen readers, large fonts, etc.

1 Like
12

[Whoops, premature “Send”, this is the real thing.]

To be clear, I did not mean to say that making a site accessible requires it to be accessible with text based browsers, strong ARIA support is (as you already said). However, accessibility is more than being nice to screen readers, it is being nice to any (sensible) form of accessing the site, including non-/limited-JS agents (be it a browser, braille device, bot, et al.).

While making Discourse editable by non-JS agents is certainly not in scope for the project (and rightly so, at least for the time being), making it readable and navigatible for those agents is relatively straightforward and IMHO important for this software (though still not easy).

Sidenote: There are more reasons for JS not being available for an agent than missing/limited support or the user having disabled the feature, e.g. when there is a Network error or Internet access is poor (as in many many places even in the Western hemisphere! e.g. I’m currently browsing ultra-slow on my phone since I went past my monthly budget) or a proxy/ISP strips or manipulates the code (as it happens in many corporate environments and has happened with mobile providers!). Sometimes the user is just not in control of the network/his environment, and this will still be true in 10 years. At least reading & navigating should be possible in those situations.

1 Like
13

I’ve been getting feedback from screen reader users on TuDiabetes and we’ve made improvements based on their findings. They use JAWS and NVDA. It would be great to have more contributions, so let us know what we’re missing.

5 Likes
14

As I’ve written in my full post (had a little issue with half-frozen fingers and bad phone UI, sorry about that), any reasonable way of accessing the website should be considered. Netscape 4 is obviously not relevant, Lynx is debatable, though not necessarily a sufficient reason to improve some aspects of Discourse.

Indeed that should be the focus.

If there is any chance to have Discourse render directly accessed pages on the server instead of pushing everything to the client, would help in a lot of cases (not only – or mostly – regarding accessibility, depending on how you understand “accessibility”).

1 Like
15

We have in the past worked with 2 blind users to improve things (@MarcoZehe and @ndarilek ) see:

We received advice from @stevefaulkner an expert in the field and acted on it.

We will continue to improve Discourse based on feedback.

As it stands the biggest pain point, which is a devil to solve is Email parsing. At the moment our parser requires the response is “at the top” if it is inlined or anything non-traditional stuff gets rejected. That tripped @MarcoZehe last time when he tried to respond. I would like to improve on it and we are logging all email failures so we can extrapolate better logic.

8 Likes
16

I received a message on our forum from a blind user who has recently signed up. He has expressed some disappointment with the accessibility of Discourse when used with a screen reader and I’m wondering if there is anything we can do to help.

Here is the message:

Hi there.

I am a blind person. I live in the village and would very much like to be an active participant on and contributor to this site. I have however had to ask someone to help me sort out sending this message.

I appreciate this forum is run by volunteers but I have to say it is one of the most impenetrable and inaccessible websites I have visited in a long time. To start with, all the buttons for taking actions of various types appear to be unlabelled graphics and my screen reading software simply announces them as lists of letters, numbers and symbols. In addition, navigating around the site is incredibly difficult given the layout and format that has been chosen.

I am far from being an IT expert. To me, IT is definitely a means to an end. I wonder though whether there is anyone involved with putting this site together, maintaining it or administering it who could do something about making it more accessible? I do hope so as I think it could be a really useful, local forum but as things stand, I am finding it so hard to use that it really isn’t worth the effort for me personally. I do hope something can be done to make it easier to use for everyone.

Thanks,
Mike

I have read through the linked topics here and appreciate that the team has desires to improve accessibility but I am wondering if it is one of your regular usability test cases? Is there a roadmap item to work on accessibility or is it deemed accessible enough (having had no experience with screen readers, I genuinely don’t know!)?

I don’t know the specific issues but I am reluctant to put the burden on our blind users to provide specific feedback. This user in particular is non-technical, hadn’t heard of Discourse, and simply wants to take part in the forum.

Is there anything more that we can do to improve accessibility for blind users proactively rather than reactively?

Has anyone in the meta community got any experience with this? Is there any feedback I can provide? Would a guide on keyboard shortcuts help? Does anyone know if the keyboard shortcuts work well with screen readers?

Cheers,
Dan

5 Likes
17

Step 1: find out what his screen reader software is. It seems that it might be reading him item ids, for example ‘ember1126’ for the ‘latest’ button… not sure of that, though.

2 Likes
18

I am very confused about this particular piece of feedback, our buttons all have aria-label set, the “like” is labeled “like this post”, and so on. We need to know which buttons the user is talking about and which software they are using.

We very much want to fix and improve accessibility, we do need specific feedback and details on what needs fixing.

In the past we have worked with @MarcoZehe on a bunch of issues, as a result of direct feedback by him we added a large amount of aria-label tags. Additionally, we have improved our email processing a lot to allow users to interact better with our site via email. Recently, we also added a proper Reject log so we can better analyze all inbound email rejections.

My first recommendation for you @danwad is to ensure you have “incoming email” enabled. This is a must. After we need to know what software the user is using, maybe get it and try using it yourself, then report some specific issues to us?

6 Likes
19

Thanks @Sailsman63 and @sam.

I have since found out the user is using JAWS 15 but is in the process of upgrading to 17 which hopefully brings some improvements.

I have advised about the “email me for every new message” setting and I am in the process of getting a replies@ inbox for the incoming email.

I have also informed the user of the keyboard shortcuts for navigating around the forum. I noticed that when using j and k to select topics and posts a selected class is added to the selected item. As we are not using the browsers focus state, I would guess that a screen reader would not pick that up. If there is a reason we can’t use focus, maybe aria-selected is appropriate here, although focus is probably ideal?

Relevant: ARIA - Managing Focus

I will install a JAWS 17 trial and try to provide some concrete feedback.

4 Likes
20

JAWS 17 should not make any changes regarding the buttons-- it’s supported aria-label since at least 2010/JAWS12.

A note about keyboard shortcuts: be aware most screen readers form a barrier between a user’s keystrokes and the browser, so that “k” can take me to the next link or “h” can bring me to the next heading. A screen reader will hijack these keys and for good reason. It’s why keyboard shortcuts built in Javascript (and using different keys for each and every site since we don’t have any unified standards, except that they seem to be vaguely vim-like at times) are hotly debated still in standards circles and not really considered accessibility enhancements, but power user enhancements. Just because your Javascript is listening for a keystroke does not mean a screen reader has even bothered to pass it on to the browser or your Javascript in the first place.

In any case, this may be more an example of someone like that person we all know who has a lot of trouble using something like Gmail. Gmail is “technically accesisble” but it’s built for nerds and power users. I have trouble with it (guess I’m not nerd enough), because it takes the basics everyone wants (an email client should let me read mail, write mail, delete mail, forward mail, and add attachments) and overcomplicates it by adding in a buttload of feature-creeped options on top that at least I am always accidentally triggering some way or other and it just fights me all the way. However, technically, it does not discriminate against users because they have a disability.

Discourse is the same thing. It’s a glorified forum software that loads so much more fluff and stuff on top that it’s restricted to certain kinds of users. It does not progressively enhance, it assumes all its users are nerds with the latest and greatest of hardware, software, and network. It assumes their icons always load and that all people magically know what they mean (ug). This is a deliberate decision on Discourse’ part, so things like usability and accessibility considerations must be taken in that light. Also keep in mind that both Marco and Nolan are nerds too. They are developers who also happen to use screen readers, plus Marco specifically works in the accessibility space. Neither are representative of Joe User who also happens to use a screen reader. They’ll catch actual bugs, and can offer some judgement calls, but that doesn’t mean if all those issues were fixed that anyone using JAWS will effortlessly be able to figure out how to use Discourse software.

Yeah, I personally am of the “Tim Berners-Lee definition of accessible” which means progressive enhancement, working reasonably regardless of hardware/software/someone’s income level/education/disability/whatever. But the official definition is something like “does not unduly hinder or lock out users simply because they have a physical disability.” That is the definition Discourse wants to use, meaning many people looking for forum software should look elsewhere.

Lynx can work fine with any basic forum that uses forms with POST to add content. Any such forum can load Javascript that, when it runs, HIJAXes those forms into quicker AJAX requests and whatnots. Discourse does not discriminate against “visually impaired” users by not being a text-based-but-still-mostly-text forum. It discriminates against “text browser” users (among others). Even the WebAIM surveys (which yeah are self-selected and therefore probably over-represent webby nerd people who use computers regularly in all ways) show most users use the same graphical browsers non-SR users use (with less Chrome use of course).

My unsolicited advice to the Discourse devs is to continue to have users of AT (and keyboard, and touch, and speech, and and and…) continue to test Discourse and give feedback to devs, and not close issues like TechnoBear’s without fixing them, since anything that is continuously developed can continuously add new bugs you didn’t have back when, for example, Marco did some testing. It’s part of your regular QA, right? And developers are testing for accessibility as they build any new thing, for example by using an automated tester like Tenon.io right?

This will help Discourse improve and maintain its technical accessibility. And obviously any random AT user can find a bug and should report it, that’s good. But I don’t see Discourse working for stuff like Lynx any time soon, and I can’t say that counts here as accessibility issues. If there are JAWS bugs, then yes those are bugs. The email thing sounds promising, though.

10 Likes