javascript in moodle and then non javascript version...

javascript in moodle and then non javascript version...

by ryan sanders -
Number of replies: 8

is there a way... to have 3 different versions... or is it already there, in a specific theme?

  • javascript (folks able to read, listen, watch, and use keyboard and mouse or touch screen)
  • javascript non, for folks with screen readers, or were javascript is turned off.
  • javascript non+, for folks with screen readers, were a min amount of javascript can be used?
    • so that detection of say person opening a new tab, new window, moving away from browser (browser loosing focus), could be captured? 
    • or an event such as a javascript timer and running audio file with a "bell sound" noting time finished?
    • or distance learning. were student in one place, teacher in another place.  and teacher clicking button "turn to next page" and audio file playing, "please click on next page"

i understand javascript screen readers and javascript = bad. more so when javascript replaces and/or adjust content on the page. i want to avoid that in 3rd type. and be able to detect / do other stuff. that might be specific to an age group, or disability. 

  • another example might be "deaf" and causing a button or page or like to "flash" at a given time, or bring attention to "turn to next page" by displaying something across page. 


Average of ratings: -
In reply to ryan sanders

Re: javascript in moodle and then non javascript version...

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

What you say was true a few years ago.

However, technology has caught up. Providing you follow the best practices (make everything work with the keyboard as well as the mouse, use ARIA attributes to make it clear what things are, and when they change, ...) the JavaScript-heavy sites can be very accessible.

So, you can use JavaScript.

Average of ratings: Useful (1)
In reply to ryan sanders

Re: javascript in moodle and then non javascript version...

by Andrew Lyons -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Hi Ryan,

As Tim says, this is no longer a requirements within Moodle. Screen readers have caught up with standards and are now able to process changes through JavaScript. Furthermore, we no longer require a non-JS version of code in Moodle (we used to). We have also removed the "Screenreader" and "AJAX" settings within Moodle and expect all code to return the same output.

There is one class on the body which we still insert - `jsenabled`. This is added by a piece of Javascript during the page load and historically was used to allow theming based on whether the browser supported JavaScript. See the CSS for action-menu as an example of how this has been typically used.

Most browsers these days make it much harder to turn off JavaScript. For Firefox you must go under the hood and disable it in the settings registry. There really isn't a good reason that I'm aware of to disable JS. I'm also unaware of any way to detect when a user has opened a new tab, window, etc. Some browsers may give browser window lost clues, but as far as I'm aware, these are non-standard.

With screenreaders, there is no need to play any sound to alert the user that a page has done something, or has finished loading, etc. The correct use of ARIA attributes such as aria-live, aria-describedby, etc. will ensure that things are announced.

In addition to all of the above, I'm not aware of any way to reliably detect the presence of a screenreader (in fact, I'm not aware of any at all). Doing so could be argued to be a breach of user privacy (e.g. user tracking, advertising etc.), and both users and screenreader developers argue that the same content should be provided to both sighted, and non-sighted users and should have the correct markup.

With regards your third point, I'm not aware of anything in Moodle core which does this at present anyway. What are the options for sighted and non-deaf users there? The content should be accessible to all, regardless of abilities. Either way, you would need to look at a community plugin for this functionality.

Best wishes,

Andrew

Average of ratings: -
In reply to Andrew Lyons

Re: javascript in moodle and then non javascript version...

by ryan sanders -

thx Tim, have yet to read over the link you gave in depth.

Andrew thx for reply! 

  1. disabled javascript = ad blockers, locking stuff up along with firewalls / antivirius software. admin's just disabling it, due to they simply do not know or want to deal with javascript issues. 
  2. firefox -> developer -> toggle tools -> gear icon top right corner of frame -> disable javascript
  3. will look further at link Tim noted further. though it is just not screen readers. color blind, and adjusting colors that are more easily distinguishable by the person. deaf of course, 
  4. privacy issues. *shrugs* could care less about it.  this development. will let the legal folks figure out the rest. 
  5. onfocus/onblur i have see it done a few many times in games, playback of video and audio files. quick google search keywords (switch tab javascript event)... first link that was returned... http://stackoverflow.com/questions/1038643/event-for-when-user-switches-browser-tabs 
  6. i want more interaction. it does not have to be blind/deaf/color blind/ other disability.  different age groups K-12, to different outside training not in an institution but a bit more specialized doings.   i want/need to know limits outside of moodle, and in moodle. 
    1. purpose of this thread is geared towards... https://docs.moodle.org/28/en/Game_Logic_in_Moodle tis a open source research project at moment. fill free to add/edit to it.

==================

question 1

  1. www.yoursite.com/moodle
  2. login as a editing teacher or higher in course
  3. turn on editing
  4. create or edit a resource
  5. restrict access (completion / availability options)
    1. how you click add, and everything "auto builds" right in browser without page refresh. is this bad or good? as far as the ARIA? 


question 2

  1. www.yoursite.com/moodle
  2. login as a editing teacher or higher in course
  3. turn on editing
  4. create or edit a resource
  5. the "drop down section menus" i assume this is ok for ARIA?

question 3

file upload drag/drop box through out moodle activities / resources... is ok with ARIA?

==============

if it seems like nitpicking, ya maybe i am, but it is not intended, i simply do not know. and it seems like i would need to know this. 

Average of ratings: -
In reply to ryan sanders

Re: javascript in moodle and then non javascript version...

by Andrew Lyons -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Hi Ryan,


1) Ad blockers should not disable JavaScript. If Admins disable it, they need to be educated. We're in 2015. The days of disabling JS for funsies have left us. I don't know of any ad blockers, firewall, or AV checker which disables JS.

2) That's hardly a use-case. We are supporting real users. Real users do not run with the developer tools continuously open.

3) There are browser extensions for colour blind folk, and all themes are designed to be high colour contrast. There are so many different types of colour blindness, we cannot cater to all.

4) You could care less about this, but the screen reader's developers and users do. They *DO NOT* make this information available to us and, in my opinion, nor should they.

5) Yes - but that is intrusive and not necessarily helpful. If you want to do this on your system, then you can write a local plugin. Often people have multiple windows open, and want to be able to view both at the same time - reading from one, writing notes or looking at references in another. Not-focused != not in use. It drives me nuts when Facebook pauses a Video I'm watching in one window while I have something else open. I have multiple monitors - let me use them!

6) You will have to look at the JS yourself here - it's not a part of core Moodle

Q1: AFAIK, it's good ARIA. I haven't looked at it in any great detail

Q2: "drop down section menus"? What are these? If you mean the expanding forms, then I believe that they are good for accessibility. In fact, I was chatting to a blind user on Friday who uses NVDA who started the conversation by telling me how much he loves them and how they work really well with the screen readers he was using (NVDA, Jaws, and VoiceOver).

Q3: Define okay? I doubt whether many blind users will use any of the drag/drop functionality. We don't actually recommend it for them. Drag/drop file upload is largely beyond our control; and we provide an alternative method for moving resources because drag/drop is *very* hard for screen readers.

I suggest that you take a look at the ARIA specification, the authoring practices, and other documentation at http://www.w3.org/WAI/intro/aria.php

Andrew

Average of ratings: -
In reply to Andrew Lyons

Re: javascript in moodle and then non javascript version...

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

3) Actually, Andrew, you are wrong here. Or at least, you give the wrong impression.

We should be doing visual design for the standard Moodle Themes which does not cause problems for the vast majority of colour blind users.

There are minimum contrast requirements in WCAG (By the way, the Atto toolbar buttons fail meed the AAA or AA requirements.)

There is the general accessibility guideline that you don't use colour as the only way to convey certain information.

Also, there are tools like http://colorfilter.wickline.org to let you see your site sort-of as a colour-blind user would. (http://blog.eyequant.com/2013/07/02/108-million-web-users-are-color-blind-how-do-they-see-your-website/ is also worth reading. I found that in the same Google search.)

Average of ratings: -
In reply to Tim Hunt

Re: javascript in moodle and then non javascript version...

by Damyon Wiese -
Picture of Core developers Picture of Moodle HQ Picture of Plugin developers Picture of Testers
I know - I raised it and it snowballed. https://tracker.moodle.org/browse/MDL-41739
Average of ratings: Useful (1)
In reply to Damyon Wiese

Re: javascript in moodle and then non javascript version...

by ryan sanders -

alright so ARIA = 

<something ARIA-xyz="yadayada">text or image or what not here </something>    

seems easy enough.   and it looks like there is enough notation to cover average and a little bit more for advanced websites. 

=====================

<quote user=Andrew>

5) Yes - but that is intrusive and not necessarily helpful. If you want to do this on your system, then you can write a local plugin. Often people have multiple windows open, and want to be able to view both at the same time - reading from one, writing notes or looking at references in another. Not-focused != not in use. It drives me nuts when Facebook pauses a Video I'm watching in one window while I have something else open. I have multiple monitors - let me use them!

</quote>

i know the feeling of wanting to use multi monitors and multi windows. BUT... most folks that i know are not internet savy.  

use of such might be... test taking and a "closed test"  not an open book test. or data mining, tracking students. i agree there are many bad uses of such behavior. but what are good uses of it?  and is there a setting within the web application. to turn it on/off / adjust the setting. 

=====================

*arghs* not liking were this could easily lead to  "web operating system", or rather "web desktop" with user profile settings errr (monitor settings, theme settings,, language, keyboard settings, mouse settings, etc...), and a whole few more cans of worms opened.

=====================

*rubs chin* wai-aria

is there some good files / plugin that anyone might recommend within moodle. that gives a few good examples of "aria" being used? i am trying to remember moodle code. but i do not remember "aria" coming up. 


Average of ratings: -
In reply to Tim Hunt

Re: javascript in moodle and then non javascript version...

by Andrew Lyons -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Sorry Tim,

I didn't mean to give the wrong impression. Yes, we should be using appropriate contrast but, as I say, there are many types of colour blindness and it isn't really possible to cater to them all sadly. We should definitely keep high contrast, and we should never convey meaning through colour.

Andrew

Average of ratings: -