www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Usability of D for Visually Impaired Users

reply Walter Bright <newshound2 digitalmars.com> writes:
https://news.ycombinator.com/item?id=12424656

It is our ethical duty to make D and dlang.org usable for visually impaired 
programmers. If any of you are visually impaired, or have programmer 
friends/colleagues who are, a review of what we can do to improve would be 
appreciated.
Sep 04 2016
next sibling parent reply w0rp <devw0rp gmail.com> writes:
On Sunday, 4 September 2016 at 20:01:21 UTC, Walter Bright wrote:
 https://news.ycombinator.com/item?id=12424656

 It is our ethical duty to make D and dlang.org usable for 
 visually impaired programmers. If any of you are visually 
 impaired, or have programmer friends/colleagues who are, a 
 review of what we can do to improve would be appreciated.
A noble goal. The trick is probably all in careful use of markup. alt tags, aria text, tab ordering. You can probably test various pages on the site by listening to the output of screen readers.
Sep 04 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/4/2016 5:15 PM, w0rp wrote:
 A noble goal. The trick is probably all in careful use of markup. alt tags,
aria
 text, tab ordering. You can probably test various pages on the site by
listening
 to the output of screen readers.
The thing is, I have no idea how experienced screen reader programmers do things. So we kinda need their help, rather than us naively trying a reader. If I was building a race car, I wouldn't ask a newbie driver to give me feedback on how it handles!
Sep 04 2016
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 05/09/2016 5:20 PM, Walter Bright wrote:
 On 9/4/2016 5:15 PM, w0rp wrote:
 A noble goal. The trick is probably all in careful use of markup. alt
 tags, aria
 text, tab ordering. You can probably test various pages on the site by
 listening
 to the output of screen readers.
The thing is, I have no idea how experienced screen reader programmers do things. So we kinda need their help, rather than us naively trying a reader. If I was building a race car, I wouldn't ask a newbie driver to give me feedback on how it handles!
w0rp's suggestion is the industry standard. Unless of course you have a few million to throw at this and still not succeed (note I did not say fail).
Sep 04 2016
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Monday, 5 September 2016 at 05:20:28 UTC, Walter Bright wrote:
 On 9/4/2016 5:15 PM, w0rp wrote:
 A noble goal. The trick is probably all in careful use of 
 markup. alt tags, aria
 text, tab ordering. You can probably test various pages on the 
 site by listening
 to the output of screen readers.
The thing is, I have no idea how experienced screen reader programmers do things. So we kinda need their help, rather than us naively trying a reader. If I was building a race car, I wouldn't ask a newbie driver to give me feedback on how it handles!
I second wOrp. While it is true that a person with normal sight has no way of knowing how screen readers are used (believe me it's pretty impressive), I know from my experience with working with visually impaired people that the best thing is a proper, clean and simple markup and _no_ fancy stuff like Flash, heavy use of JS and the like. Most screen reading software can parse and handle HTML very well. So the first priority is proper markup. Then one can fix the few glitches left with the help of the `aria-label` property. A blind user I worked with used D for a term paper and he could find his way around on dlang.org. So it seems to be pretty ok already. We should only be careful with new stuff like language tours and tutorials. They should all be marked up properly and have no buttons or links that are invisible to screen readers.
Sep 05 2016
next sibling parent reply Kagamin <spam here.lot> writes:
On Monday, 5 September 2016 at 09:14:12 UTC, Chris wrote:
 a person with normal sight
No love for people between normal and blind?
Sep 05 2016
parent reply Chris <wendlec tcd.ie> writes:
On Monday, 5 September 2016 at 09:34:13 UTC, Kagamin wrote:
 On Monday, 5 September 2016 at 09:14:12 UTC, Chris wrote:
 a person with normal sight
No love for people between normal and blind?
Sorry, I sure ain't gonna list all conditions between 20/20 and blind. This is about IT not PC ;) Anyone who can see normally with or without glasses has "normal sight" _in this context_. If you need a 500% zoom to discern letters on the screen, you are visually impaired (but not blind). There are people who use zoom and screen readers at the same time etc. But that's beyond the point we're discussing.
Sep 05 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/5/2016 2:52 AM, Chris wrote:
 Sorry, I sure ain't gonna list all conditions between 20/20 and blind. This is
 about IT not PC ;) Anyone who can see normally with or without glasses has
 "normal sight" _in this context_. If you need a 500% zoom to discern letters on
 the screen, you are visually impaired (but not blind). There are people who use
 zoom and screen readers at the same time etc. But that's beyond the point we're
 discussing.
True, but too many sites lose their formatting if one increases the font size with the Ctrl-+ command. Us >50 fossils who wear progressive lenses get tired of bobbing heads to read the screen and just boost the font a bit. You can always tell a user interface designed by a youngling :-) This was a few years ago, but Apple's web site technical documentation used to use a tiny grey font on a white background. It was literally painful to read, making me just not want to support OSX.
Sep 05 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/5/2016 2:14 AM, Chris wrote:
 A blind user I worked with used D for a term paper and he could find his way
 around on dlang.org. So it seems to be pretty ok already. We should only be
 careful with new stuff like language tours and tutorials.
This is good to hear. But with constant changes to dlang.org, it can be very easy to slip away from that, especially with all the pressure to "modernize" the look-and-feel with crap. We'll need constant vigilance!
Sep 05 2016
parent Chris <wendlec tcd.ie> writes:
On Monday, 5 September 2016 at 20:59:46 UTC, Walter Bright wrote:
 On 9/5/2016 2:14 AM, Chris wrote:
 A blind user I worked with used D for a term paper and he 
 could find his way
 around on dlang.org. So it seems to be pretty ok already. We 
 should only be
 careful with new stuff like language tours and tutorials.
This is good to hear. But with constant changes to dlang.org, it can be very easy to slip away from that, especially with all the pressure to "modernize" the look-and-feel with crap. We'll need constant vigilance!
I agree, the webpage should comply with accessibility rules consistently and not fall foul of flashy design when adding to the homepage. As regards the zoom: most browsers handle the zoom very well (Ctrl+'+') these days. Visually impaired users often use the zoom that comes with the screen reading software or the inbuilt, OS-specific zoom (cf. Apple's Voice Over, Windows also a zoom as far as I know).
Sep 06 2016
prev sibling next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 09/04/2016 10:01 PM, Walter Bright wrote:
 https://news.ycombinator.com/item?id=12424656

 It is our ethical duty to make D and dlang.org usable for visually
 impaired programmers. If any of you are visually impaired, or have
 programmer friends/colleagues who are, a review of what we can do to
 improve would be appreciated.
As I've worked on the website quite a bit, here are some things we're already doing for accessibility: * We use proper markup: headings, lists, etc. * The site adapts to zooming and large font settings, using the same mechanism as for small windows/screens. * We're keeping the traditional underlines on links to help color blind people identify them. Though we did remove the underlines in menus and such. We hope it's obvious that the text can be clicked there. * We have fallbacks for (I hope) all the JavaScript functionality. Regarding screen readers, I don't know if anyone has tested the site with a screen reader. I haven't. Overall, we have relatively simple content. So I'd hope that dlang.org is at least usable. Unfortunately, the page with the most eye-candy and dynamic features is the home page. So the first page someone opens is probably the most difficult to navigate with non-visual tools.
Sep 05 2016
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Monday, 5 September 2016 at 12:24:37 UTC, ag0aep6g wrote:

 As I've worked on the website quite a bit, here are some things 
 we're already doing for accessibility:

 * We use proper markup: headings, lists, etc.

 * The site adapts to zooming and large font settings, using the 
 same mechanism as for small windows/screens.

 * We're keeping the traditional underlines on links to help 
 color blind people identify them. Though we did remove the 
 underlines in menus and such. We hope it's obvious that the 
 text can be clicked there.

 * We have fallbacks for (I hope) all the JavaScript 
 functionality.
I think the above points should do the trick.
Sep 05 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/5/2016 6:09 AM, Chris wrote:
 I think the above points should do the trick.
Probably, but there's nothing like actually testing it.
Sep 05 2016
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Mon, 05 Sep 2016 14:24:37 +0200, ag0aep6g wrote:
 * We have fallbacks for (I hope) all the JavaScript functionality.
Can confirm; dlang.org is one of the few sites that works exactly as expected with NoScript and RequestPolicy etc turned up as high as they'll go.
Sep 05 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/5/2016 8:14 AM, Chris Wright wrote:
 On Mon, 05 Sep 2016 14:24:37 +0200, ag0aep6g wrote:
 * We have fallbacks for (I hope) all the JavaScript functionality.
Can confirm; dlang.org is one of the few sites that works exactly as expected with NoScript and RequestPolicy etc turned up as high as they'll go.
This is awesome - great work!
Sep 05 2016
prev sibling parent reply Sai <test test.com> writes:
I have few suggestions, especially for people like me with 
migraine, it could be a bit easy eyes and overall less stressful.

1. The "Jump to" section at the top lists all the items available 
in that module nicely, but the layout could be improved if it 
were listed as a bunch of columns instead of one giant list with 
flow layout.

Even better if they are listed as the "cheat sheet" available in 
algorithm module (which is lovely BTW). Can this cheat sheet be 
automated for all modules?


2. I know red is the color of Mars, is there any way to change 
the theme to blue or something soft? Since we can download the 
documentation, is there an easy way to do it myself maybe?


PS: As many people have already said, documentation has improved 
very very much recently. Thank you for all the people working on 
it.
Sep 06 2016
parent ag0aep6g <anonymous example.com> writes:
On 09/06/2016 08:47 PM, Sai wrote:
 1. The "Jump to" section at the top lists all the items available in
 that module nicely, but the layout could be improved if it were listed
 as a bunch of columns instead of one giant list with flow layout.
That's a solid idea. Unfortunately, variance in name length is large. Might be hard to find a good column width. But it's definitely worth exploring.
 Even better if they are listed as the "cheat sheet" available in
 algorithm module (which is lovely BTW). Can this cheat sheet be
 automated for all modules?
The newer, DDOX-based version of the documentation has generated tables like that. You can find those docs here: http://dlang.org/library-prerelease/index.html It's supposed to become the main/default form of documentation soonishly. One thing we have to figure out is how to consolidate the hand-written cheat sheets with the generated ones. For example, std.algorithm modules currently have both. That's confusing for the reader.
 2. I know red is the color of Mars, is there any way to change the theme
 to blue or something soft?
Principally, we could offer an alternative stylesheet with another color. That's going to be forgotten during maintenance, though, especially if the demand for it is low.
 Since we can download the documentation, is
 there an easy way to do it myself maybe?
You can of course edit the stylesheet. In the zip, that's dmd2/html/d/css/style.css. The color codes for the different reds are mentioned in a comment at the top. I hope they're up to date. A couple search/replace operations should take care of most of it. The logo is colored independently. It's a relatively simple SVG file. Just edit the "background" color in dmd2/html/d/images/dlogo.svg. I'm not sure if this qualifies as "easy".
Sep 06 2016