Tag: accessibility

Hack/Doc Fest at Butler: Day 3

The ten people who attended Moodle Hack/Doc Fest stand on either side of stylized block letters that spell out the word "Moodle".. The
Moodle Hack/Dock Fest at Butler University attendees. (back row, left to right) Ken Newquist, Charles Fulton, Jason Alley, Deryl Botta, Ruth Schwer, Matt Wright (front row, left to right) Kristi Burch, Adam Dinnes, Joe Bacal, Jedidiah Rex

As the final day of Hack/Doc Fest at Butler wrapped up the team continued its accessibility work, reviewed the course overview plugin, and discussed our upcoming Moodle 3.1 recommendation.

Accessibility

On Day 2 we created a long “scroll of death” course with numerous accessibility issues baked in. On Day 3 we began building out the improved versions of this course using stock Moodle, the grid course format, and the collapsed topics course format.

Work on the courses will continue beyond Hack/Doc. Next steps include:

  • Evaluating the updated courses with various accessibility tools to verify that we truly fixed all the problems.
  • Writing a blog post describing the various issues with the badly-designed version and how they were addressed in the fixed ones.
  • Publishing the courses to a “Moodle Museum” category in the CLAMP Moodle Exchange.

In addition we discussed having a having a “Moodle Accessibility” online hangout in July and contributing the example courses to Moodle core for use in their demo site.

Related to these efforts we looked at how to create an “accessibility” toggle for the Grid Course Format that lets users switch between the grid-style course and the default topics course. Issue #23 in the Grid format project discussed ways of doing this but it took some experimentation to make it a reality.

Our “Providing an accessible option to Grid Course Format” documentation explains how to do this.

Course Overview on Campus

Matt Wright from Butler University demonstrated their use of the Course Overview on Campus plugin. The plugin replaces the default “my courses” page with a dropdown that lets the user browse through all the course categories on the system. How the courses are listed (e.g. title, short code, teacher) is configurable. The list still includes course-specific action items (e.g. a course assignment needs review) but it is concealed in a collapsed content area by default.

The category selected is preserved between sessions, so if user choses the “Fall 2016” category it will be there waiting for them the next time they log in.

Working on a Moodle 3.1 Recommendation

We will be working on our recommendation for Moodle 3.1 over the next week and hope to have it published on June 29. At this point we don’t see any major blockers, but there are a few things (like annotation in the assignment submission view, whether to turn on the Competencies feature, and improvements to cron) that colleges should consider before upgrading.


Posts from Moodle Hack/Doc Fest at Butler University: HomepageSprint | Day 1 | Day 2 | Day 3

Hack/Doc at Butler: Day 2

Moodle spelled out using variable sized artistic block letters
Moodle becomes art thanks to the “Word Art” exhibit in Butler University’s Irwin Library. Photo credit: Ken Newquist

During Day 2 of Hack/Doc Fest at Butler the team tackled a review of third-party plugin compatibility with Moodle 3.0 and 3.1, continued our accessibility work by testing new tools and documenting best practices, reacquainted ourselves with the Workshop plugin, and delved deeply into Moodle 3.1’s new Competencies feature.

Plugin Review

We compiled a list of popular 3rd party plugins for Moodle and then determined if they are compatible with 3.0 and 3.1. Of particular note were the following plugins, which list compatibility with 3.0 but not 3.1:

  • Course Overview
  • TurnItIn
  • McGraw HIll

Course Overview was tested under 3.1 and seemed to work just fine. That said, the way it is configured changed in 3.1; it is now difficult to get to all of the settings on one unified page.

View the full list of third-party plugins.

Accessibility and Course Design

Continuing our work from Monday, we created a “scroll of death course” — aka an exceedingly long course — with a variety of accessibility issues. The course was created using the TinyMCE WYSIWYG editor, but edited using Atto.

As expected, Atto couldn’t fix much of what had been done incorrectly using TinyMCE, if for no other reason than it didn’t have the same editing options. Many of the problems in the course had to be fixed by going into the source HTML and editing it there.

Once the new course is completed, we’re going to create the following example courses that address the “scroll of death” issue while improving accessibility and usability:

  • an accessible course using stock Moodle
  • an accessible course with Collapsed Topics course format
  • an accessible course with the Grid course format

We also intend to look at an option that allows students to switch switch course formats (e.g. grid to topic) to help with accessibility. This requires the user to set a custom profile field called “accessibility” which — when toggled — lets them switch to a designated “accessible” course format.

Screen Readers

We spent some time experimenting with screen readers on Moodle and other websites. We started with ChromeVox, a plugin for Chrome that allows you to tab through a page and reads the elements to you. The lack of mouse support made it more difficult to use and there isn’t an obvious way to toggle the plugin on and off.

We experimented with TalkBack on Android. It works great, but it radically transforms the way you use your phone and introduces a number of double and triple click command for common tasks. It requires you to re-learn how to how to navigate your phone.

We also researched optical character recognition techniques and found ConvenientOCR is a plugin for JAWS. This plugin lets you mouse or tab over an image and then OCR it. We did not get to try this plugin, but it sounds promising. JAWS itself is an expensive piece of software that only runs on Windows, but there is a free trial version for those who want to check it out.

Annotations Workflow

We continued our review of the new Assignment Submission view and the problems associated with it (see MDL-54165 New grading interface should hide “editpdf” if unoconv is not enabled and MDL-54818 Improve assignment PDF annotation).

A number of schools are planning on turning off the PDF annotation component of Moodle until the issues with it are resolved. However, before turning off the feature we wanted to know how many people were using that particular feature at our institutions. We created an ad hoc query that looks for the use the annotation feature in Moodle assignments by identifying occurrences of “comments” and “annotations” in the database.

The annotation query is available through CLAMP’s Github; it requires the ad-hoc database queries plugin to run.

CLAMP House Cleaning

We fixed two issues with the CLAMP website. We’ve resolved the SSL cert error that occurred when you tried to browse www.clamp-it.org under https. We also fixed a bug that would redirect you to an account sign-up page when accessing http://clamp-it.org.

Printing Quizzes in Moodle

We continued looking at ways to print quizzes and documented a technique involving embedding a quiz within a “book” within Moodle. View the documentation.

Workshop

We revisited Moodle’s Workshop module and found it to be a good peer assessment tool and fairly easy to set up. The tool has different student grading options including

  • comments, no grades
  • comments and grades
  • rubrics (which are different than assignment rubrics)

Competencies

We spent considerable time at Hack/Doc reviewing Competencies and have come to the conclusion that it’s a complicated new system with an inherent workflow that isn’t well documented.

Here’s how the documentation describes Competencies:

“Competencies describe the level of understanding or proficiency of a learner in certain subject-related skills:”

In brainstorming use cases for competencies at our colleges the scenarios that stood out the most were those where some sort of interdisciplinary or cross-institutional outcomes needed to be tracked. For example, a writing program that establishes a set of skills that students should develop during their time at the college. Evidence of acquiring competency in those skills could be provided in a variety of ways:

  • Evidence submitted by students
  • Evidence submitted as part of a course activity
  • Evidence submitted by faculty for students.

Moodle Competencies handle this through three tools:

  • Competencies: The building blocks of the system, competencies establish a specific goal, and provide a mechanism for giving evidence that the goal has been met.
  • Competency Frameworks: A collection of competencies.
  • Learning Plans: A method for pushing out a particular set of competencies (possibly taken from multiple frameworks) to students.

The single biggest challenge with Competencies is that it assumes you have an existing offline workflow and framework and want to implement it in Moodle. If you have those things, we expect that the tool makes a lot more sense. If you don’t, then the published documentation isn’t going to help understand the usefulness of the tool or how to implement it at your college.

In addition, Competencies itself has an implied workflow that isn’t obvious to laypeople. For example, there is a process for students or faculty to request review of competency evidence. The per-student requests for such review appear on the “My Moodle” page, but it’s not clear if there is a place where faculty or learning plan managers could go to see the progress of an entire student cohort (e.g. not just an individual student’s progress toward meeting competency goals, but the entire cohort’s progress).

The development documentation does a much better job of explaining the purpose of Competencies and does a better job of explaining how the various pieces fit together.

* Dev: Competencies
* Dev: Competency-based Education


Posts from Moodle Hack/Doc Fest at Butler University: HomepageSprint | Day 1 | Day 2 | Day 3

Hack/Doc at Butler: The Sprint Day

The white, aquaduct-like facade of Irwin Library at Bulter University
The exterior of Irwin Library at Butler University. Photo credit: Ken Newquist

CLAMP kicked off Moodle Hack/Doc Fest on Monday, June 21 with our traditional sprint day. The sprint day exists for everyone to get a jump on the week’s work — a few people (in this case, most of those attending Hack/Doc) arrive early, resolve any logistical challenges (getting to campus, connecting to the local network, making sure sources of caffeine are available throughout the day), and start organizing the week’s worth.

During this sprint we came up with our usual tasks list in Google Drive and people signed up for the things they were interested. Then, in a fit of spontaneous documentation, everyone started using that tasks list to provide updates on their progress. It’s not a thing we’ve done before, but it’s working out very well — it provides a running log of what we were working on, and it’s more efficient because we don’t need to spend as much time reporting out each day.

Topics identified include:

  • Accessibility – Making Accommodations for Users with Disabilities
  • Managing the “scroll of death” on course pages within Moodle
  • The practical implementations of layering quizzes over video
  • Evaluate the Moodle Mobile app
  • Printing from Moodle
  • The Recycle Bin plugin in Moodle (new feature in Moodle 3.1)
  • Evaluate the Mass Action block (3rd party plugin)
  • Evaluate Competencies (new feature in Moodle 3.1)
  • Test out the Global Search
  • Document, test, and name the new umbrella course plugin (3rd party plugin)
  • Look at other major changes in Moodle 3.1
  • Review anonymous forums in Moodle 3.1 (Moodle Liberal Arts Edition)
  • Review Ad-hoc database queries (customsql) (Moodle Liberal Arts Edition)
  • Best practices for using Moodle with other schools

Hack/Doc attendees can view the task list in Google Docs; the initial draft of the list is available in the CLAMP Moodle Exchange.

In the course of our work we came across a gnarly problem involving the new assignment review interface. This interface allows the user to see a student’s submitted assignment alongside all the relevant grading fields (e.g. add a grade, comments, etc.). The student’s work is rendered as a PDF and the teacher can use Moodle’s annotation capabilities to mark up the paper with their responses. The end result is saved as a PDF and sent to the student as feedback.

The problem is with the PDF. If students submitted a PDF, then the process works reasonably well. If they submitted a Word or Open Office document instead, Moodle converts it to PDF for display … or tries to. If you do not have a specific helper application known as unoconv installed on the server (and in our experience, it’s unlikely you will have it), then the PDF conversion fails. Instead you get a blank page. That blank page can then be edited with the annotation tools and submitted as feedback, but that’s not particularly helpful since the student’s original assignment isn’t included.

This is documented in MDL-54165 New grading interface should hide editpdf if unoconv is not enabled and is flagged as a critical bug in Moodle 3.1. The proposed resolution to the bug is to revise the interface to allow it to fail gracefully when this tool isn’t available. We encourage the CLAMP community to watch and vote for this issue.


Posts from Moodle Hack/Doc Fest at Butler University: HomepageSprint | Day 1 | Day 2 | Day 3