# Accessibility concerns re email, Lynx, JAWS

**URL:** https://meta.discourse.org/t/accessibility-concerns-re-email-lynx-jaws/35675
**Category:** Feature
**Created:** [2015年十一月17日 05:29 UTC](https://meta.discourse.org/t/accessibility-concerns-re-email-lynx-jaws/35675 "2015-11-17T05:29:11Z")
**Posts on this page:** 5
**Page:** 2

<div class="post-metadata">

### Author: ![erlend\_sh](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/erlend_sh/32/119475_2.png) [@erlend\_sh](https://meta.discourse.org/u/erlend_sh)
#### Post date: [2016年二月26日 22:38 UTC](https://meta.discourse.org/t/accessibility-concerns-re-email-lynx-jaws/35675/21 "2016-02-26T22:38:56Z")

</div>

Thanks for the in depth feedback. It’s a shame about the keyboard-shortcut incompatibilities.

Since some of these tools expect plain HTML, perhaps the best alternative in this case is a [richer HTML interface](https://meta.discourse.org/t/html-mode-with-email-integration/39685).

---

<div class="post-metadata">

### Author: ![Stomme\_poes](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/stomme_poes/32/108689_2.png) [@Stomme\_poes](https://meta.discourse.org/u/Stomme_poes)
#### Post date: [2016年二月27日 00:16 UTC](https://meta.discourse.org/t/accessibility-concerns-re-email-lynx-jaws/35675/22 "2016-02-27T00:16:20Z")

</div>

It’s not so much that they expect plain HTML. It’s just the keystroke thing is a known thing.

Javascript on focusables don’t have this problem for example: listening for keystrokes on form controls, links and buttons should always work.

Also, certain roles on elements should also alert a screen reader to pass on keystrokes-- the question then is just one of support, spec robustness, etc. I recently ran across this with drag and drop: supposedly if your drags and drops occur in elements with list and tree roles, keystrokes should be passed on.

However sometimes developers need other HTML (non-lists, non-trees… these are kind of restrictive honestly), and in my case even doing everything right worked everywhere except JAWS in IE. For that, we added role=“application” which can force the SR to pass on keystrokes, but this is one of those powerful dangerous tools as you’re basically taking all navigation and tools away from the user and claiming you can meet all their needs with your own JS. And that’s often a pretty bold claim to make (so for this reason, role=application is meant to be used sparingly, and on the smallest part of a page or app as you can manage… and if there’s any plain text inside that container with role=application, you need to wrap that back in a role=“document” to give reading/nav keystrokes back to the user so they can read).

I think Discourse can work with screenreaders-- remember, the shortcuts like j/k etc are for keyboard-only power users who are not using AT. Users of AT _already have similar keyboard shortcuts_ if your code is sufficiently structured, so that’s not necessarily a problem. You can have two kinds of people surfing the same site in two different, but fairly equivalent, ways.

But with an application this javascripty it takes some devs on the team who know more about this area, and it needs AT users to test and report bugs (also screen mag users, keyboarders without AT, Dragon users etc).

---

<div class="post-metadata">

### Author: ![grahamperrin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/grahamperrin/32/71406_2.png) [@grahamperrin](https://meta.discourse.org/u/grahamperrin)
#### Post date: [2016年十一月16日 03:26 UTC](https://meta.discourse.org/t/accessibility-concerns-re-email-lynx-jaws/35675/23 "2016-11-16T03:26:27Z")

</div>

> [@fbender](#):
>
> … Lynx is debatable, though not necessarily a sufficient reason to improve some aspects of Discourse.&nbsp;…

I tested with Lynx following interest from valued community members who are sometimes (or often) in areas with low bandwidth; who typically prefer Lynx in such situations.

Not a long test (only ten minutes or so), but enough to be pleased with the appearance, the orders of things and so on. An example screenshot:

 ![](https://global.discourse-cdn.com/meta/original/3X/c/e/ce18f30846989d2834fc8e6545e1c2c798200406.png)

Without detracting from the foci on accessibility:

- please, how much effort might be required to enable **log&nbsp;in** for users of Lynx?

Beyond that point: from what I saw of the NLI (_not_ logged in) views, I assume that already there is support for most of the features that logged&nbsp;_in_ users will treat as essential or desirable.

* * *

Side notes:

- should tags in meta include _accessibility_? (I found no more recent/relevant topic for Lynx)
- noted in Firefox, with thanks, the Discourse response to keying `End`. Wow&nbsp;:clap:

---

<div class="post-metadata">

### Author: ![edanto](https://avatars.discourse-cdn.com/v4/letter/e/8e8cbc/32.png) [@edanto](https://meta.discourse.org/u/edanto)
#### Post date: [2017年一月17日 19:07 UTC](https://meta.discourse.org/t/accessibility-concerns-re-email-lynx-jaws/35675/24 "2017-01-17T19:07:03Z")

</div>

Have you had a chance to evaluate Discourse for ease of use with a screen reader since your last post a year ago @Stomme_poes ?

Does anyone else know if any improvements have been made since the most recent big discussion on accessibility about year ago on the other similar thread [Accessibility software and discourse - #52 by codinghorror](https://meta.discourse.org/t/accessibility-software-and-discourse/13711/52)

---

<div class="post-metadata">

### Author: ![chapoi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/chapoi/32/537252_2.png) [@chapoi](https://meta.discourse.org/u/chapoi)
#### Post date: [2025年十二月4日 11:37 UTC](https://meta.discourse.org/t/accessibility-concerns-re-email-lynx-jaws/35675/25 "2025-12-04T11:37:07Z")

</div>



[上一頁](https://meta.discourse.org/t/accessibility-concerns-re-email-lynx-jaws/35675.md?page=1)
