Arrow keys for navigation of HTML output

[rbeezer]

Readers (students) have requested that the keyboard arrow keys might function like the prev and next buttons. Maybe this is a CSS/Javascript function, or maybe something MBX should write out. Maybe this would be an accessibility improvement?

Maybe check that the MathJax accessibility functions don't get clobbered.

[rbeezer]

http://stackoverflow.com/questions/1402698/binding-arrow-keys-in-js-jquery

[Alex-Jordan]

If the buttons for prev/up/next had HTML id's, then some javascript could bind the left, up, and right arrow keys to these buttons.

http://www.codingforums.com/javascript-programming/220575-control-web-page-buttons-arrow-keys.html

[davidfarmer]

I assume the javascript will be read from the web, not embedded on the page?

How about we do that right after we sort out how we are going to host javascript and CSS?

We can add Ids to the buttons now, which won't do anything initially.

prevbutton upbutton nextbutton

What should the down button do?

On Sun, 2 Apr 2017, Alex Jordan wrote:

If the buttons for prev/up/next had HTML id's, then some javascript could bind the left, up, and right arrow keys to these buttons.

http://www.codingforums.com/javascript-programming/220575-control-web-page-buttons-arrow-keys.htm l

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.[AAM6LK7nC9XcJCETA6rVduFzhTCiKCNpks5rsCmVgaJpZM4KrnFh.gif]

[Alex-Jordan]

So, I looked up that link, and almost posted what I composed as a new issue before I found this one existed. I pasted it here before following Rob's link, and it may be better.

I'm interested in "left/right", not so much "up". Red flags go up when I think about "up", because maybe that is the usual way to scroll up when keyboard navigating.

So I should ask accessibility staff about it.

Are we opposed to putting js directly into pages, even when it is very concise like this would be?

[davidfarmer]

I agree about not changing the behavior of the up arrow, and feel ashamed that I didn't catch that.

I'm generally opposed to putting the javascript on the page, and would like to carefully evaluate what we already have. But I have not thought about it beyond not wanting to have it in my way when I view the page source.

On Sun, 2 Apr 2017, Alex Jordan wrote:

So, I looked up that link, and almost posted what I composed as a new issue before I found this one existed. I pasted it here before following Rob's link, and it may be better.

I'm interested in "left/right", not so much "up". Red flags go up when I think about "up", because maybe that is the usual way to scroll up when keyboard navigating.

So I should ask accessibility staff about it.

Are we opposed to putting js directly into pages, even when it is very concise like this would be?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.[AAM6LJTZWzDZaiLSm8ydKn_Te7ZD95LXks5rsDAcgaJpZM4KrnFh.gif]

[rbeezer]

EZ to add once we decide just which ones. I'd vote for just left/right and reserve up/down for some movement of the actual page content. Let me know when a decision is final and it'll take me 5 minutes.

Check that. We already have classes

previous-button up-button next-button

Like David, I'd prefer JS all be in a file of its own, then we can update that file with new features and 2-year-old sites get new goodies automatically (though not if they require new ids, classes, etc). And we don't need to be making new XSL to add new features like this. Witness MathJax mess.

We already have mathbook.js.

So it appears you don't need me. ;-)

Rob

On 04/02/2017 04:32 PM, Alex Jordan wrote:

So, I looked up that link, and almost posted what I composed as a new issue before I found this one existed. I pasted it here before following Rob's link, and it may be better.

I'm interested in "left/right", not so much "up". Red flags go up when I think about "up", because maybe that is the usual way to scroll up when keyboard navigating.

So I should ask accessibility staff about it.

Are we opposed to putting js directly into pages, even when it is very concise like this would be?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/issues/433#issuecomment-291023087, or mute the thread https://github.com/notifications/unsubscribe-auth/ABy2cgGXodnsFF8btkc3HPXOXyc2duUjks5rsDAcgaJpZM4KrnFh.

[Alex-Jordan]

I may not understand these things fully, but I don't think classes are enough. You want something that is unique to the button (an id) so that the javascript associates the keystroke with one specific button. Not (in principle) many buttons that could have the same class.

On Sun, Apr 2, 2017 at 10:21 PM, Rob Beezer notifications@github.com wrote:

EZ to add once we decide just which ones. I'd vote for just left/right and reserve up/down for some movement of the actual page content. Let me know when a decision is final and it'll take me 5 minutes.

Check that. We already have classes

previous-button up-button next-button

Like David, I'd prefer JS all be in a file of its own, then we can update that file with new features and 2-year-old sites get new goodies automatically (though not if they require new ids, classes, etc). And we don't need to be making new XSL to add new features like this. Witness MathJax mess.

We already have mathbook.js.

So it appears you don't need me. ;-)

Rob

On 04/02/2017 04:32 PM, Alex Jordan wrote:

So, I looked up that link, and almost posted what I composed as a new issue before I found this one existed. I pasted it here before following Rob's link, and it may be better.

I'm interested in "left/right", not so much "up". Red flags go up when I think about "up", because maybe that is the usual way to scroll up when keyboard navigating.

So I should ask accessibility staff about it.

Are we opposed to putting js directly into pages, even when it is very concise like this would be?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/issues/433#issuecomment-291023087, or mute the thread https://github.com/notifications/unsubscribe-auth/ ABy2cgGXodnsFF8btkc3HPXOXyc2duUjks5rsDAcgaJpZM4KrnFh.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/issues/433#issuecomment-291051068, or mute the thread https://github.com/notifications/unsubscribe-auth/AEg3AIXi-Wdmkrh4mIpWWQP8xXW6iu6Zks5rsIHygaJpZM4KrnFh .

-- Alex Jordan Mathematics Instructor Portland Community College

[rbeezer]

On 04/02/2017 11:13 PM, Alex Jordan wrote:

You want something that is unique to the button (an id)

Right - I wasn't reading close enough. Though in practice, I think our use of these classes is unique.

We could

(a) add an ID

(b) convert existing classes to ids and change existing CSS to select on the id, but I guess that would be a backward-incompatible change that would break existing hosted projects.

[davidfarmer]

I suggest we add ids to all three buttons (even though we have no plans for the up button, and those ids be the class name but without the hyphen. No change to CSS.

On Mon, 3 Apr 2017, Rob Beezer wrote:

On 04/02/2017 11:13 PM, Alex Jordan wrote:

You want something that is unique to the button (an id)

Right - I wasn't reading close enough. Though in practice, I think our use of these classes is unique.

We could

(a) add an ID

(b) convert existing classes to ids and change existing CSS to select on the id, but I guess that would be a backward-incompatible change that would break existing hosted projects.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.[AAM6LARGbMfnQK6NDeJ5Q4aIwhrGYOS_ks5rsQw_gaJpZM4KrnFh.gif]

[rbeezer]

I've added id=previousbutton, id=upbutton and id=nextbutton to the HTML output. I added them to the "disabled" versions of the buttons as well. Let me know if that causes problems or needs to change and we can adjust. I'll update the sample article online once home tonight.

50a9398d

Rob

[Alex-Jordan]

I had not pulled mathbook in a while. Now I get lots of these when making html:

element span: validity error : ID previousbutton already defined
element span: validity error : ID upbutton already defined
element a: validity error : ID nextbutton already defined
element a: validity error : ID previousbutton already defined
element a: validity error : ID upbutton already defined
element a: validity error : ID nextbutton already defined
element a: validity error : ID previousbutton already defined
element a: validity error : ID upbutton already defined
element a: validity error : ID nextbutton already defined
element a: validity error : ID previousbutton already defined
element a: validity error : ID upbutton already defined
element a: validity error : ID nextbutton already defined
...

I believe that we have seen this kind of thing before, and the reason I see it and Rob (I'm guessing) does not is either a Mac/Linux difference or a version difference in xsltproc. I don't remember how to address it though...

[rbeezer]

Looks like there is one duplicate on each page. There is a set of buttons for the top for while in desktop mode and a set of buttons at the bottom for while in mobile mode.

(a) Do we just put them on the top and presume small screen mode has no arrow keys? (This might catch out anyone who zooms a lot on desktop and wants to navigate with arrows.)

(b) Or do we put different ids on them? id="upbutton-top"

I'm not clued-into the code that will use these, so I'm not sure which is best. Either will solve the immediate problem.

Rob

On 04/09/2017 03:18 PM, Alex Jordan wrote:

I had not pulled mathbook in a while. Now I get lots of these when making html:

|element span: validity error : ID previousbutton already defined element span: validity error : ID upbutton already defined element a: validity error : ID nextbutton already defined element a: validity error : ID previousbutton already defined element a: validity error : ID upbutton already defined element a: validity error : ID nextbutton already defined element a: validity error : ID previousbutton already defined element a: validity error : ID upbutton already defined element a: validity error : ID nextbutton already defined element a: validity error : ID previousbutton already defined element a: validity error : ID upbutton already defined element a: validity error : ID nextbutton already defined ... |

I believe that we have seen this kind of thing before, and the reason I see it and Rob (I'm guessing) does not is either a Mac/Linux difference or a version difference in xsltproc. I don't remember how to address it though...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/issues/433#issuecomment-292817697, or mute the thread https://github.com/notifications/unsubscribe-auth/ABy2csT-e9YKWdF1XmWNgz_WDdLXtE8Oks5ruVlDgaJpZM4KrnFh.

[Alex-Jordan]

I am not a web designer. However, my first thought is "why are there two buttons"? As in, why does not the CSS reconfigure the position and styling of the "top" button when the screen gets small, instead of invoking a different button? Related: if focus is on a "top" button and a user zooms in to smallscreen mode, where will focus be?

On Sun, Apr 9, 2017 at 3:38 PM, Rob Beezer notifications@github.com wrote:

Looks like there is one duplicate on each page. There is a set of buttons for the top for while in desktop mode and a set of buttons at the bottom for while in mobile mode.

(a) Do we just put them on the top and presume small screen mode has no arrow keys? (This might catch out anyone who zooms a lot on desktop and wants to navigate with arrows.)

(b) Or do we put different ids on them? id="upbutton-top"

I'm not clued-into the code that will use these, so I'm not sure which is best. Either will solve the immediate problem.

Rob

On 04/09/2017 03:18 PM, Alex Jordan wrote:

I had not pulled mathbook in a while. Now I get lots of these when making html:

|element span: validity error : ID previousbutton already defined element span: validity error : ID upbutton already defined element a: validity error : ID nextbutton already defined element a: validity error : ID previousbutton already defined element a: validity error : ID upbutton already defined element a: validity error : ID nextbutton already defined element a: validity error : ID previousbutton already defined element a: validity error : ID upbutton already defined element a: validity error : ID nextbutton already defined element a: validity error : ID previousbutton already defined element a: validity error : ID upbutton already defined element a: validity error : ID nextbutton already defined ... |

I believe that we have seen this kind of thing before, and the reason I see it and Rob (I'm guessing) does not is either a Mac/Linux difference or a version difference in xsltproc. I don't remember how to address it though...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/issues/433#issuecomment-292817697, or mute the thread https://github.com/notifications/unsubscribe- auth/ABy2csT-e9YKWdF1XmWNgz_WDdLXtE8Oks5ruVlDgaJpZM4KrnFh.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/issues/433#issuecomment-292818693, or mute the thread https://github.com/notifications/unsubscribe-auth/AEg3AOVpsidp5VCIT_OkpdEI0Htc_GDFks5ruV3rgaJpZM4KrnFh .

-- Alex Jordan Mathematics Instructor Portland Community College

[Jahrme]

It appears possible to move the buttons using CSS. I found a simple example here (on StackOverflow) of moving a div to the top or bottom of the view depending upon the screen size.

(Not saying that the linked method would be ideal for our purpose, simply that it is possible.)

[davidfarmer]

The location of the buttons, including the fact that there are two sets of buttons, it tied up with the javascript that does the responsive page layout. I think it is asking for trouble to try changing that right now.

We do hope to overhaul the CSS, and that would be a good time to take a look at this.

For now, I suggest putting the id's only on the buttons at the top. When I get a chance, I will insert the code that will make the left and right arrows function as prev and next.

Good idea or bad idea: once that is working, modify the "Skip to main content" to also say that the left and right arrows work as prev and next.

If that is not a good idea, then how will people who do keyboard navigation know that those arrows do something?

[rbeezer]

On 04/09/2017 05:17 PM, davidfarmer wrote:

The location of the buttons, including the fact that there are two sets of buttons, it tied up with the javascript that does the responsive page layout. I think it is asking for trouble to try changing that right now.

Definitely.

We do hope to overhaul the CSS, and that would be a good time to take a look at this.

Yes.

For now, I suggest putting the id's only on the buttons at the top. When I get a chance, I will insert the code that will make the left and right arrows function as prev and next.

Sounds good.

Good idea or bad idea: once that is working, modify the "Skip to main content" to also say that the left and right arrows work as prev and next.

If that is not a good idea, then how will people who do keyboard navigation know that those arrows do something?

Alex has inquired of his experts.

[rbeezer]

Thanks, Alex. Errors should be gone now, id's are only on top buttons, and bottom buttons have nothing.

Live now at sample article at website, so available for testing David, whenever you get the urge.

Thanks, Jahrme, for the CSS pointer - we might find that useful when we dig into this further.

Rob

[Alex-Jordan]

I'm not seeing any new commits. Did you push to GitHub?

On Sun, Apr 9, 2017 at 7:55 PM, Rob Beezer notifications@github.com wrote:

Thanks, Alex. Errors should be gone now, id's are only on top buttons, and bottom buttons have nothing.

Live now at sample article at website, so available for testing David, whenever you get the urge.

Thanks, Jahrme, for the CSS pointer - we might find that useful when we dig into this further.

Rob

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/issues/433#issuecomment-292838041, or mute the thread https://github.com/notifications/unsubscribe-auth/AEg3AOXL-stgPS4naeddA4SirC234e4pks5ruZoKgaJpZM4KrnFh .

-- Alex Jordan Mathematics Instructor Portland Community College

[Alex-Jordan]

Got it now.

On Sun, Apr 9, 2017 at 8:21 PM, Alex Jordan alex.jordan@pcc.edu wrote:

I'm not seeing any new commits. Did you push to GitHub?

On Sun, Apr 9, 2017 at 7:55 PM, Rob Beezer notifications@github.com wrote:

Thanks, Alex. Errors should be gone now, id's are only on top buttons, and bottom buttons have nothing.

Live now at sample article at website, so available for testing David, whenever you get the urge.

Thanks, Jahrme, for the CSS pointer - we might find that useful when we dig into this further.

Rob

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/issues/433#issuecomment-292838041, or mute the thread https://github.com/notifications/unsubscribe-auth/AEg3AOXL-stgPS4naeddA4SirC234e4pks5ruZoKgaJpZM4KrnFh .

-- Alex Jordan Mathematics Instructor Portland Community College

-- Alex Jordan Mathematics Instructor Portland Community College