Below is a list of “accessibility goals” for the OnDemand 2.x five year project. The first year’s focus will be on these goals, though other goals may also be addressed:
Improve Job Management
Reduce Administrative Load
Streamlining interface
These are explained in detail below. Please comment if you see something missing that should be included here, or if you think our prioritization is incorrect. In particular Job Management is an area where we have lots of ideas but haven’t yet decided on an approach. I’ll be updating this topic with more detail in the future.
1. Improve Job Management
OnDemand is popular for interactive work, file management and job monitoring, but not for job management. We want to address the limitations of the Job Composer and make job management a first class citizen in OnDemand. There are several approaches we can take:
Extend the Files app.
Job Submission: Allow a user to select one or more files and submit them to a scheduler.
App “shortcuts”: For example, allow a user to select a .m file and click a “go run MATLAB on this cluster” option. Automatically submits a 1-core, 59-minute job with that MATLAB file as input.
Support “Batch Apps” in Dashboard (analogous to “Interactive Apps”)
Batch App (e.g., MATLAB batch app) would allow user to specify hardware, wall time, input file(s) and output location.
Unified Jobs app “My Jobs”
Completed jobs (with stats from XDMoD)
Running jobs from scheduler (with stats from Ganglia)
Queued jobs from scheduler
Job Script IDE – writing a job script is software development!
Incorporate version control
Syntax highlighting and checking
Wizards for hardware configuration and job environment configuration (Eclipse PTP may have examples)
Lint to check script for errors
Slurm Assist from Sandstone HPC
Incorporate Galaxy or HubZero RAPPTURE for turning jobs into apps
Improve the Job Composer app
Group job directories together by “project”
Control where job directories are created
Control the name of the job directories when you make a copy of a template
Extend Job Options web form with all the resource manager options available and allow for site specific customizations
Separate between job directories and job executions in the interface
2. Reduce Administrative Load
Installation and configuration and debugging problems in OnDemand are currently difficult. Some ideas include:
Simpler plugin architecture
Centralized configuration
Configuration validation
Test suite to catch common mistakes made when configuring OnDemand.
3. Streamlining interface
Anything that can reduce the number of steps required to accomplish a task. Examples of this include one click launching of interactive apps, showing only links to apps that users use daily, improving the file manager. Many ideas have already been provided in the user survey that we are still working through.
4. Integrate jobs, files and app launching
Jobs, files and app launching are each handled by separate apps silo-ed off from each other. Integrating these together would provide options for streamlining user workflows that involve all three. Examples of this include:
double click a Jupyter notebook to start a Jupyter server with the notebook loaded
utilize a desktop metaphor for launching apps from the Dashboard
Asked about mobile friendly interface. Making the views accessible on mobile devices is something that requires some work but is necessary. An open question remains, what work do you want to do on a mobile device?
This isn’t the type of “accessibility” your roadmap lists here so I’m not sure if this post is off topic, but is there any consideration for making Open OnDemand Section 508/WCAG compliant. Maybe it already is. I’m not a web accessibility expert, but when I saw the topic of accessibility, this is what I thought of.
We haven’t discussed this yet. If we would ever want to support something like this we should probably take it into consideration when making interface decisions for supporting OnDemand 2.x. For example, one consideration was leveraging Jupyter Lab or the underlying PhosphorJS library. It looks like Jupyter Lab’s accessibility audit is still open, so addressing all the associated issues related to Section 508/WCAG compliance is not a trivial task, and the complication could be increased or decreased based on the complexity of the interface.
We’ve had an offline discussion about the WCAG stuff I thought appropriate to bring back into Discourse and capture here:
From Eric:
Google Lighthouse looks awesome, thanks!
In regards to accessibility in OnDemand, there is a difference between:
1. improving the adherence to accessibility standards in the OnDemand code to satisfy the requirements of an OSU audit or WCAG compliance tools
2. making actual work with OnDemand possible using only a screen reader and a keyboard (no mouse)
You can achieve the first without achieving the second. In regards to the first, it would be good to know how much of OnDemand needs to be accessible to meet OSU standards.
Some examples of accessibility problems in OnDemand:
1. interactive VNC apps in OnDemand are not accessible because they use NoVNC which is an HTML5 canvas based VNC client that relies on a mouse. You can’t drive a desktop or Matlab through NoVNC using only a keyboard.
2. The fact that all of the apps open in new windows are problematic as well
3. There is not consistent top navigation banner across every page (because many pages are from different web servers)
From Chris:
I use Google Lighthouse when doing accessibility audits. I believe it’s built into the Chrome developer tools by default (under the “Audits” tab choose to audit “accessibility”).
Ran a couple of quick audits on ondemand and it looks like you only have a few minor issues to review.
From Kyle:
They did not mention any dates to security coordinators as the official push was in its infancy still. I checked their site and noticed they assigned coordinators for the Office of Research so we can reach out to them to find out more details if we would like: [Jennifer Otterbein.3](mailto:otterbein.3@osu.edu), [Marne Weinberger.12](mailto:weinberger.12@osu.edu). We would have to check with them on tools available as they are separating this information from the security coordinators.
The policy that will be followed:
https://accessibility.osu.edu/digital-accessibility-policy/minimum-digital-accessibility-standards/
From Alan:
Taking this conversation off Discourse for a little bit and looping in Doug, Chris and Kyle. A couple quick comments / observations:
1. I recall Kyle saying that OSU is going to be pushing / auditing webpage accessibility? If so, do we know the details / timing of that and what we’ll need to do / what tools will be available to us?
2. Looking at the WCAG guidelines at w3.org, it appears to me that we likely meet the majority of them already with OOD. I’m sure there are some we don’t, but they don’t seem too complicated or hard for us to address.
3. There are a variety of tools that check for WCAG compliance, but I don’t know how we could do that with a website that requires authentication and dynamically changes based upon what you select like OOD. Chris do you have any thought / input on this?