Web accessibility of Sage cells

[Alex Jordan]

I work on MathBook XML and WeBWorK, both of which make use of Sage cells. So first I want to thank this community for their work on this project. My institution strongly supports web accessibility and recently they were conducting some accessibility testing of the HTML generated by MathBook XML. Specifically they were looking at this sample page. They encountered an accessibility issue with the Sage cell and I'd like to discuss it here.

A keyboard navigator might have a visual disability and use a screen-reader. Or might have mobility impairments and be unable to use a mouse. Or maybe there are more reasons. But the idea is to support users who navigate a site with a keyboard only. The tab key is perhaps the main tool for these users. A user tabs from way point to way point, typically through links and other landmarks with the right attributes.

But at that sample, if you attempt to navigate with the tab key, you eventually enter the Sage cell and are seemingly stuck there. The accessibility staff here refer to it as a "keyboard trap". The tab key has a fundamental Python role and can't be used to escape from the Sage cell, so it's not clear what to do about this. Has this community thought about accessibility issues with Sage cells?

Being able to navigate in and out (or around) the cell somehow would probably be a first issue to look into. If the cell received focus, then rather than putting the cursor into action in the input field, maybe some extra action (like spacebar which activates a button with focus, or enter, which activates a like with focus) could bring the user into the input field. That would address navigating into or around the Sage cell, but still leaves the question of how to get out.

[Jason Grout]

How about escape to leave the editor and focus the div around the editor, like in the Jupyter notebook?

--
You received this message because you are subscribed to the Google Groups "sage-cell" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-cell+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-cell/168bc398-7812-4bb4-a767-b8771f9428db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Farmer]

Would tab then get you to the evaluate button? I think that
would be a common use case.

And then when you hit Evaluate, the focus would go to the
div with the answer? That would be similar to what we are
discussing for knowls.

[Jason Grout]

Perhaps ESC should just focus the evaluate button directly. It's hard to know what is best without trying it out for a while, I think.

Jason

--
You received this message because you are subscribed to the Google Groups "sage-cell" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-cell+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-cell/alpine.LRH.2.20.1612010852140.9728%40li375-150.members.linode.com.

[Rob Beezer]

In the past, Alex has been able to have a student actually test this sort of
thing, while being videorecorded for analysis. Maybe that would be an option
once something is in place (or Alex's accessibility expersts could be consulted
about various options).

Rob

On 12/01/2016 08:16 AM, Jason Grout wrote:
> Perhaps ESC should just focus the evaluate button directly. It's hard to know
> what is best without trying it out for a while, I think.
>
> Jason
>
>
> On Thu, Dec 1, 2016, 08:54 David Farmer <far...@aimath.org
> <mailto:far...@aimath.org>> wrote:
>
>
> Would tab then get you to the evaluate button? I think that
> would be a common use case.
>
> And then when you hit Evaluate, the focus would go to the
> div with the answer? That would be similar to what we are
> discussing for knowls.
>
> > How about escape to leave the editor and focus the div around the editor,
> like in the
> > Jupyter notebook?
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-cell" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-cell+...@googlegroups.com

> <mailto:sage-cell%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-cell/alpine.LRH.2.20.1612010852140.9728%40li375-150.members.linode.com.
> For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to the Google Groups
> "sage-cell" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to sage-cell+...@googlegroups.com

> <mailto:sage-cell+...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sage-cell/CAPDWZHw5WO929zZ%2Bax0gFFSO42r16D57vPxhL%2B-0srvfS0S9jw%40mail.gmail.com
> <https://groups.google.com/d/msgid/sage-cell/CAPDWZHw5WO929zZ%2Bax0gFFSO42r16D57vPxhL%2B-0srvfS0S9jw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Alex Jordan]

I'm arranging for some user testing by at least one screen reader user, possibly
two, likely to take place on Friday December 16. I will be present with the end user,
and possibly another staff member will be present to manage recording the session.

I'm planning to do testing with some MathBook XML, knowl, and MathJax issues we
are curious about. With those things, the issues I want to test are things I can tweak
on the fly to experiment with different options.

However I don't think I have the skill set to do this with the Sage cells. So if it's possible
for members of this community to mock up several potential solutions before this session
happens, I'll enthusiastically gather that testing feedback and report here with a link to
the video capture.

[Alex Jordan]

The staff here confirm that with conventional user expectations, ESC is the right
way to exit the cell for a keyboard navigator. Where that should take you is going
to be something to probe with the user testing.

[Andrey Novoseltsev]

I am happy to do and roll out any changes necessary, but I need some pointers on where and how they should be done technically.

A probably related request from a long time ago about voice over: https://groups.google.com/d/topic/sage-devel/Q952nMqGHjs/discussion

Thank you!
Andrey

[Alex Jordan]

Screen reader testing with a blind staff member is scheduled for Thursday Dec 15. As I
mentioned, I've scheduled this to look into a few MathBook XML and MathJax issues.
But if we can try out some Sage Cell things too, then great. If we can put some mockup
solutions to the immediate known issues, that would be ideal.

[Alex Jordan]

Thanks Andrey,

I'm sure I know much less than you about anything technical regarding Sage cells.
But I'll take a stab at it. I'm partly talking to myself below, and some things are probably
obvious to you.

According to these embedding instructions, a Sage cell is wrapped in a div with class
"sage". This is not the case with the Sage cells I have any familiarity with from MathBook
XML. They are wrapped in a div with class "sagecell-sage", like you can see in the source
in this example.

But in any case, referring to the Sage cell in the MBX example I just linked, and without
understanding the technical implications, one outline of behavior we might want would be:

1. Tabbing from earlier in the page, the containing div (class="sage" or
   class="sagecell-sage") can receive focus.
2. From there, another tab brings you to the "toggle fullscreen" button.
   
3. From there, another tab brings you to the "Evaluate Sage Code" button.
4. From the button, another tab moves focus past the Sage cell altogether.
5. When focus is back on the containing div, the enter key brings you into the input field
   with cursor live.
6. While in the input field, ESC brings you out of the input field and puts focus on either
   the containing div or the Evaluate button. (It would be worth trying both to see what
   the user feedback preference would be.)

Until we do the user testing, I'm not really sure what happens with reading the default content
of the input field, reading the line numbers, reading the output after evaluation, and tabbing
through the Help and SageMath links that appear under the output.

[Rob Beezer]

On 12/03/2016 03:40 PM, Alex Jordan wrote:
> According to these embedding instructions
> <https://sagecell.sagemath.org/static/about.html?v=076b8b4093fa6a45a81e291c7e2b8fb7#embedding>,

> a Sage cell is wrapped in a div with class
> "sage". This is not the case with the Sage cells I have any familiarity with
> from MathBook
> XML. They are wrapped in a div with class "sagecell-sage", like you can see in
> the source
> in this example

> <http://mathbook.pugetsound.edu/examples/sample-article/html/section-sage-cells.html>.

Look at the Javascript in the header, where this aspect of the configuration is
changed from the default.

For example, you can find div.sagecell-r where the default language will be
set to R in the configuration.

[Alex Jordan]

Due to inclement weather, my screen reader session for end user testing is postponed
to some time in January. If there are any experimental Sage cell elements that we could
do testing on, please post live examples somewhere and point to them from this thread.

I suspect that we will just do recorded testing on the existing basic Sage cell structure,
and then I can share that with this community to inform possible improvements