Accessible solution for help popups required

Hi,

I've worked up an example of a YUI 3 overlay/popup driven by a button, with a NO-YUI-script link to a new page. Button and link are hidden/shown as appropriate.

Note, most screenreader users will have Javascript enabled, can navigate within the YUI-overlay, and will hear the contents of the overlay (tested with Fx 3 / NVDA screen reader).

http://dl.dropbox.com/u/3203144/moodle-yui3-popup.html

I hope this helps.

Nick

http://twitter.com/nfreear

Hi Nick,

Thanks a lot for your suggested accessible solution. I've just added Petr as a watcher for his comments.

Rosie, I notice you're also watching this issue. Your comments would be appreciated too.

This is my proposal on our help icons solution. Instead of describing, you can see it in action:
1. create an account at github.com
2. create a New repository
3. click "Admin" repository button
4. try the behaviour of their help icons there

We can use YUI overlay popups so screenreaders should be fine. Note that we should have something clickable so that users of iPhones, iPods and other no-mouse-cursor devices and users preferring Vimperator-like keyboard hints can access help, too. Also, such overlay popup gives us much more space than that hover bubbles so we are not so much limited in help text length.

Another proposal: use wiki syntax for help string content

Benefit:

• much easier to write correct syntax in plain text area without tinymce editor
• no pesky <p></p> and other complex tags
• much easier to parse and convert to other formats
• smaller (less memory used)

Translators should be able to use wiki syntax already, because they are probably helping with docs.moodle.org already (it is linked from each page footer).

Hi Nick,

Thank you for creating a sample code for help popups.

After working on couple of accessibility issues, It seems that button is a preferable choice to trigger an action. In my opinion, nick's solution would be better than the github solution. With YUI, adding/removing an event such hover could be done easily.

Helen,
regarding your comment on MDL-20425 'when help is combined in other help popups', i think we could make multiple popup windows for each help where each window will have their own close button.

just for reference, MDL-20425 suggest an improvement for labeling the help icon.

IMO that demonstration at dl.dropbox.com is the worst combination of possibilities: popup automatically opened after hover + must be closed by click on its button only Can you imagine how many times users just move cursor over a help icons by moving them on the screen? I really do not want to turn Moodle pages into casinos-like sites.

Also my -1 against the possibility to have multiple help popups opened at the same time.

David,

I'm agree with you for not having the popup trigger on over.

The reason, i prefer nick's solution because the close button in the help content is accessible through click and tab. Screen reader could read the content of the popup window easily.

OK. Let is have "Close" button/link at the bottom of the popup but let us also implement it so that clicking anywhere closes the popup as well. This will increase usability while keeping accessibility. That is exactly how github help popups work.

Also, it will only display 1 popup window a time just like in github, correct?

Rossi: yes, it will.

When JS is available then I think the current solution in CVS is the best and the most usable. Hovering makes it show, and moving away makes it go away. It feels very natural just like a tooltip used through web browsers and operating systems.

When JS is not available then all we can do is go to a new page like we do now - no problem.

What I think we need to add is just:

When you have JS and you CLICK on the image (eg via a touch on a screen or some other selection device (tab key?) that doesn't hover), then the same tooltip pops up, and clicking the button again or inside the text box makes it go away. There could be an X on the text box too to close it (more like Nick's idea).

Note also that there needs to be a bit more delay on the tooltip to go away when it came up via hover, and also the "go away" should be prevented once we have our mouse in there, so that we can click links in the help or cut/paste, etc.

I know that Martin seems to be pretty sure about the required behaviour of help. I would just like to record my contra-proposal and will shut up already. My +1 goes for the help behaviour as they have at http://mahara.org/ Simply visit that page and look for the login box.

1. firstly note the icon has nice decent neutral blue color. Help icons are not expected to be used every time the user visits the page and the yellow color is very striking
2. note you have to click the icon
3. note the popup - it can contain quite long text if needed, including links, formatting etc (I would just vote for displying the popup at fixed position at the screen, not near the icon)
4. note you can click anywhere to close the help again, so getting the help info is as easy as double click and the uses is neither spammed with yellow bubbles by accidental hover nor annoying delay before the AJAX call is actually triggered

p.s. this Mahara's behaviour is the same as the one at github I was proposing above.

ping for Martin

I just realized that with the "hover in - hover out" behaviour, we can't have that "More help" link working at the bottom of the yellow bubble.

OK, David, thanks.

I like the Mahara example better than github, because it doesn't take over the screen. And it looks like getting a div that was triggered by hover on the image to STAY there during hover on the help box is going to take more time for Rosie. I was hoping hover would make it easier to browse those long forms with help buttons we had but I just realised you still need to aim correctly to the image so you might as well click.

So new plan, to summarise for Rosie what we just talked about:

Javascript on:

1. Hover over icon just shows standard browser tooltip "Help for X" like it used to in 1.9. This is implemented via title on the link, by the function that prints help buttons (already done in HEAD)
2. Clicking on the icon/link makes the floating help appear. It stays there until you either click on the X in the upper right corner, or outside the floating help (just like Mahara).
3. Clicking IN the help window does nothing (unless it's a link). Good for copying text.

Javascript off:

1. Hovering will show browser tooltips based on the title attribute, as before. (already done in HEAD)
2. Clicking will take you to a new help page via the standard link. (already done in HEAD)

The new plan to have a Mahara-like help popup sounds great to me! Thanks David, Martin and Rosie.

created patch for the help button popup (above suggestion)

I still notice the overlay positioning are off in Chrome and am going to look more into it tomorrow morning.

Please take a look.

Any feedback would be appreciated.

Thanks

Hi Rosie. Thanks for the patch. Some quick notes:

• if the help icon is too near the right border of the screen (for example in the right side bar), the overlay help window (that white bubble with the help content) gets out of the screen. The position must be fixed in this case.
• the patch add some commented lines (probably testing/development) into the code - just please be sure it is not committed
• the patch includes many trailing whitespace - please configure your IDE to either drop it automatically or (which I prefer) highlights it
• IMO

  YUI().use(...)
  

  is wrong as the YUI instance should be referred to as Y

d.

Looking close, thanks Rossi!

1. What david said
2. Just to have it noted here, pressing tab+enter isn't working yet. No rush, but should be done by release.
3. I have to say I preferred the yellow background - anyway I think the help window background should match the icon (whatever it ends up being), to make it totally distinct from the page itself. Themers can obviously change this, but I think yellow is good for standard.
4. If there is some background colour then you can avoid the heavy black border (which doesn't match the standard look at all).
5. The heading can have the 1em margin taken off the top in these popups.

fixed the position of the 'help content' to display on the left side of the icon, if the help icon is too near the right border. Change the styling for the 'help content' per martin's suggestion.

the above changes work nicely in FF. The latest patch has been committed.

In progress to fix:

• pressing tab + enter
• positioning overlay in chrome. I tried to use many different way to get the position of the icon, but had no luck. any suggestion would be appreciated.

thanks

Hi, Rossiani

The chat is broken (it uses popup)

Something is wrong with this button ('<button class="closehelpbutton" type="button" id="hide">. It's always visible which doesnt seem right. I've attached two screenshots.

I notice there is a problem when the help popup is near the bottom of the page - the bottom of the help popup is missing (see attached screenshot using Firefox on Ubuntu).

Otherwise I really like the new-style help popups. Thanks for suggesting it David, and great work implementing it Rosie!

Hi guys,

Current implementation breaks several things - problems include:

• All areas within Moodle using the openpopup function other than help (chat inc.)
• Install / upgrade: can't rely on JavaScript at this points and CSS from base is not included (close button being shown)

I've attached a patch that makes the following changes:

• renamed M.help_content to M.util.help_icon.
• render_help_icon no longer uses the popup action instead it adds a js init call to add a reference to a help icon.
• initialisation now occurs the first time a help icon is clicked rather than a call to init being included in every page.
• HTML for the overlay is added via JS rather than being a part of the page at delivery, easier on screen readers and install/upgrade compatible.

Having looked at the comments in this issue I think this patch is fine could someone please review.

Cheers
Sam

The above patch has now been commit, Rossi could you please check it out for me and make sure it still does what is intended, let me know if you have any questions.

Cheers
Sam

Thanks Sam for fixing the patch.

Addition to Sam's commit, I add 'enter' key event functionality to close the popup window.

popup window can be close by clicking anywhere outside the 'popup' window or pressing the 'enter' key.

This functionality has been committed to HEAD. Please take a look and let me know if you have any questions.

Thanks
Rosie

Wow, this looks really good!

some minor comments:

• the delay in bringing up the overlay is about 1 second, which is enough that a naive user will never find out that this feature exists because if you click on the icons as normal, it doesn't have time to come up at all before the pop up opens with a new window and if you just move the mouse around the page randomly, even quite slowly, you also see nothing. If the delay was zero, users would be very much more likely to notice this accidentally.
• the text size is smaller than the size of the text on the body of the page, which makes it slightly harder to read. It needs the standard YUI CSS to be overridden with Moodle's standard font size from the theme.
• the overlay appears below the cursor position, which often obscures the text of the thing you are asking for help about e.g. help button next to the HTML editor input. It would be slightly more useful to have it appear above the cursor so that you don't have to make it go away again to spot the icon it's talking about, before brining it back to read the rest.

Is the delay intentional, Rossiani? Or is it just YUI slowness?

Thanks Matt for you comments.

Regarding the delay on bringing up the overlay, there is no delay time is set to display it. However, when the icon is click for the first time, YUI needs to create overlay tag to the page then display it. The page will then re-use this tag to display other help content and clicking the help icon again will immediately display the overlay. The creation of overlay tag to the page might cause the 1 second delay on displaying the content.

I tested the text size using anomaly and standard themes, both themes display the content in the same size with the page. Could you tell me which there are you using?

Thanks
Rosie

Rosie,

I just found the default delay on line 187 of javascrip-static.js:

showdelay: 1000,

This works really well when changed to zero.

The size of text is with the standard theme and I've attached a screenshot.

A good deal of fiddling didn't turn up a way of altering the pop up's position relative to the cursor as thistooltip.align('bl', 'tr') only recognises the first element that the listener it's attached to and keeps placing the tooltip relative to it (when called from line 208) so that seems unalterable to me.

Matt, I think your code is quite old! The popups were rewritten since your version

Whoops, my bad! That's what I get for using an out of date dev server at work instead of my laptop.

I now have the updated code and it all looks great.

Good job everyone!