caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Adrien Nader <adrien@notk.org>
To: caml-list@inria.fr
Subject: Re: [Caml-list] [ANN] Prose v1 - a collaborative text editor
Date: Thu, 13 Jul 2017 08:38:22 +0200	[thread overview]
Message-ID: <20170713063822.GA17433@notk.org> (raw)
In-Reply-To: <20170711152432.5n4mybmxg4twsjlv@pl-59055.rocqadm.inria.fr>

Hi,

On Tue, Jul 11, 2017, Sébastien Hinderer wrote:
> Dear Adrien,
> 
> Many thanks for your prompt and positive response!
> 
> Adrien Nader (2017/07/11 15:09 +0200):
> > Hi Sébastien,
> > 
> > On Tue, Jul 11, 2017, Sébastien Hinderer wrote:
> > > Dear Adrien,
> > > 
> > > I find it awesome that such a tool is developed in OCaml and wish it all
> > > the possible success.
> > > 
> > > Has accessibility already been taken into account? Is there any plan on
> > > this for future developemnt? I am asking because most of the pads I know
> > > lack this feature.
> > 
> > Accessibility has not really been taken into account so far. However I
> > definitely see that as an issue. My main problem with doing it is that
> > this is not a field I know and I definitely welcome pointers to
> > resources I could learn from.
> 
> Well, I am not an expert either. I mean, I face accessibility issues as
> a user, but that does not necessarily mean I know how to fix them as
> people tend to believe. I should probably learn that, too.
> 
> The W3C has a work group on accessibility, the WAI (Web Accessibility
> Initiative).
> 
> This group has published:
> - The WCAG, Web Content Accessibility Guidelines:
> https://www.w3.org/WAI/intro/wcag
> - Tge ATAG (Authoring Tools Accessibility Guidelines):
> https://www.w3.org/WAI/intro/atag
>  
> And a few other documents that may be a bit less relevant here.
> 
> I also did a little presentation on accessibility. It is not focused on
> web accessibility but may be of interest to those curious about how
> blind people use computers:
> http://brl.thefreecat.org/conf.mkv
> 
> The presentation is in french, sorry about that.
> 
> And the video has a bug (when I run X the content of the screen is not
> displayer), I hope this will be fixed soon.

Thanks for the links. I have poked a few people on IRC too and there's
now a fair bunch of links in the ticket.

> > Actually, my own machines typically force white text on dark
> > backgrounds, including for web pages. As such I already avoid things
> > that wouldn't render properly (CSS and font icons) and try to label
> > interactive elements (although I haven't managed to do it for everything
> > yet, see e.g. https://gitlab.com/adrien-n/prose/issues/42 ).
> > 
> > That said, this also depends on Ocsigen and I don't know how well it
> > fares on this. IIRC there are APIs related to accessibility but I
> > haven't looked at them and I can't tell whether they cover everything
> > needed (it's not unlikely they do).
> > 
> > It's also important to take the JS library into account. I think it
> > doesn't fare too bad in this aspect but I haven't checked properly.
> > 
> > There are also some features that I don't know how to make accessible.
> > On a graphical display, and especially with colors, it is easy to notice
> > edits from others without being interrupted. This relies either a lot on
> > peripheral vision, or on eyes being able to quickly jump to the proper
> > position when the text suddenly shifts after words or lines are
> > inserted. Hopefully, while these situations happen, they are not the
> > norm. Material to learn from is welcome for this too.
> 
> I am not sure how to make such features accessible either. Intuitively,
> I have always thought that a pad that can be modified by several persons
> in parallel is intrinsically inaccessible. However, I don't know whether
> this is actually true or not. And even if it's true, there may be some
> kind of "best effort" way to provide at least some degree of
> accessibility. I will investigate on this.

That would be tremendously helpful. The software is already planned to
be able to extract information from the content (the outline at least)
and more may be added but presenting that well to blind users is
something I have troubles designing. That said, such information and
notices can also be an unwanted distraction including to non-blind
users.

> > All in all, this is going to take a few months to get into the code but
> > again there are many things that still need to be done.
> 
> I think it's really not a big deal if it takes time. Roughly speaking we
> start with "nothing" (no accessible alternative at all) so any single
> thing happening would be an improvement over what currently exists.

 :) 

> > rhere is already a ticket on gitlab about this:
> > https://gitlab.com/adrien-n/prose/issues/24 . It is not very detailed
> > and I guess I'm both missing some things and wrong on others so input is
> > welcome. :)
> 
> When you are blind, sometimes it's even difficult to simply
> figure out what exactly is not working or what you don't have access to,
> because you don't have access to it. I mean, say there is a button to
> underline something. If the screen reading system does not present this
> button to me, I won't be able, by myself, to tell you that this button
> is not accessible, because I don't even know it's here.
> 
> That's why, IMO, sometimes the most effective way to progress is to
> physically meet and see together what works and what does not. If you
> are in Paris and would like to, we could organise such a meeting.

I am indeed in Paris and believe meeting would be very helpful.
There's probably a bit of homework I should do first however: there are
for sure several issues that I can already notice and fix.

Best,

-- 
Adrien

  reply	other threads:[~2017-07-13  6:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-06 12:13 Adrien Nader
2017-07-06 22:39 ` SP
2017-07-11 11:53 ` Sébastien Hinderer
2017-07-11 13:09   ` Adrien Nader
2017-07-11 15:24     ` Sébastien Hinderer
2017-07-13  6:38       ` Adrien Nader [this message]
2017-07-13  6:52         ` Sébastien Hinderer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170713063822.GA17433@notk.org \
    --to=adrien@notk.org \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).