ONS and Javascript

[OrielSullivan]

ONS and Javascript
I’m thinking now about how to make the tool attractive to/adaptable for ONS……….the accessibility issues I agree can be dealt with by our new techie employee, as per Thomas’s specs for the position.
But there was another issue raised by ONS, about Javascript. The head of the relevant section at ONS (who we know and are communicating with) wrote the following to us:
“The other important consideration is that all the basic components of the tool must not be reliant on javascript - in effect, javascript can only be used for polish rather than providing some core function within the tool. “
I don’t understand why this is, and I don’t think he necessarily understands it either – it sounds like something he’s been told (he's not an expert)! But I’m thinking from the Github % bar showing languages used that what you are doing is probably mostly in Javascript? How easy would it be to change that – is this something we could add to the list for the new employee? Question from total ignorance: could ChatGPT convert languages?!

[andreifoldes]

Very interesting. Is this related to the "progressive enhancement" philosophy of the GOV.UK do you think? see https://www.gov.uk/service-manual/technology/using-progressive-enhancement . Their position is understandable in that some people have Javascript disabled on their devices and the in the name of accessibility it seems that in an ideal world this would not be an exclusion criteria for participating in government funded research.

Yes, you are right we are using a lot of Javascript, primarily for improving user experience, but also for one crucial feature which is the "resizeable" activity block feature (e.g.: dragging the left and right edges of the activities in the horizontal view)... this type of user interaction cannot be facilitated without Javascript unfortunately.. what can be done is having a "fallback"/"minimal" mode where a different input mode appears for participants who have JS disabled... for example a dropdown menu (HTML is limited in its "interactive" features https://www.w3schools.com/html/html_form_elements.asp)... but to be clear this would be barely comparable to the actual app from a research perspective, but it would perhaps help the app qualify for ONS approval...

I do think its a worthy cause to make the app work in such an "impoverished"/"restrictive" environment, but as researchers we also need to ask ourselves ... are all my participants using the "same" app, can I treat the data as similar. I would argue any non-JS version would not be equal to the original app.

[OrielSullivan]

Yes, exactly, I think that's it. Thanks for sending the link. I wonder if we can address this with our new (still-to-be) recruit as part of the general accessibility issue. Would a 'click at start'/'click at end' of the activity with a zoom function (which we have discussed in the context of accessibility for people with motoric issues) be possible without JS?

[andreifoldes]

Yes, I think that's great task for them! Unfortunately when one is restricted to using HTML (and CSS) alone without JavaScript the possibilities are very limited, so a Zoom functionality would not be possible. But we could have a click for start, click for end approach! I remember you asked for this anyway so creating this would be solving two accessibility hurdles with one fix which is great! Perhaps something like ...

While this maybe the best HTML only way of doing TUDs, its very hard to enable "finetuning" activity durations in this design, whereas this is very easy in the drag-based resizing approach..

[OrielSullivan]

That's really neat, gives something to work towards!