The following outlines recommendations from the Accessible Moodle project to improve the accessibility of UCL Moodle for disabled students and staff, as well as improve usability for all users. These have been informed by focus groups with disabled students and staff; analysis of how UK websites adhere to accessibility guidelines; and research of relevant journal articles and accessibility guidelines.

Our primary aim is to ensure Moodle is technically accessible using assistive technologies including ZoomText, JAWS screen-reader, Read & Write, Dragon NaturallySpeaking voice recognition software, as well as other assistive technologies commonly used at UCL. In addition, keyboard-only access should be fully supported. It is also important that UCL Moodle is usable for those with disabilities, as well as the wider student and staff community.

In order to develop these recommendations, the project team ran focus groups with UCL students and staff with disabilities, to find out what they found difficult to use within Moodle and what suggestions they had for improvements. I have blogged previously about the background to the project and the outcomes of these focus groups.

A number of sources were also referenced to see how Moodle could be made to better adhere to accessibility guidelines. The most important of these are the following three guidelines from the World Wide Web Consortium (W3C) :

• Web Content Accessibility Guidelines (WCAG) 2.0 Level AA for making Moodle and its content more accessible.
• Web Accessibility Initiative – Accessible Rich Internet Applications Suite (WAI-ARIA) for designing Moodle so users of assistive technologies, like screen-readers, can navigate and read its pages.
• Authoring Tool Accessibility Guidelines (ATAG) for making the Moodle rich text editors more accessible.

A number of websites were also analysed to compare how each of them implemented W3C guidelines.

The list that follows is a wish list, which may not all be implemented, but gives us a guide for how we might improve Moodle. Although there are many other elements that are important, but not mentioned below, the following makes a start of improving the interface for disabled  and non-disabled users alike.

We are taking a multi-faceted approach to resolve the issues identified, and work is likely to be ongoing, but here’s a list of changes we’d like to see made to make Moodle more accessible.

Assistive Technology compatibility.

The following recommendations are likely to require implementation at multiple levels, so don’t easily fit under any single development areas below. The project aims to achieve the following:

• Content and editing features are available to screen-readers, or suitable alternatives are available – e.g. offline marking in Word enables in-line marking for assessments.
• Navigation is straight-forward, with content appearing before menus and appropriate headings, links and lists being utilised to enable easy navigation using common screen-reader features. E.g. the list of module tutor names under every Moodle course name in the search results means that hundreds of links are listed to screen-reader users and sighted users are overwhelmed by irrelevant information which needs to be scrolled past, and which is particularly problematic for those with dyslexia.
• All images have alt tags (even if these are empty), or in the case of icons that supplement text, they use ARIA tags to tell screen-readers to ignore them.
• Accepts user input using voice recognition software, like Dragon Naturally Speaking.
• Enables magnification by ensuring the pages display well when the browser is zoomed in or when zooming software is used.
• Visible focus when using the keyboard (tab, space, enter and arrow keys) to navigate.
• Supports the use of OpenDyslexi font, available as a browser plugin to help those with dyslexia read text.

A multi-faceted approach

The following five areas outline the different ways in which Accessibility improvements can be made to UCL Moodle.

1. A new, more accessible UCL Moodle theme for use on desktop and mobile devices.
   • Minimise clutter, by enabling blocks to be hidden and removing extraneous information.
   • Position elements for optimal access. E.g. ensure the login is prominent and important course features are easy to access.
   • Simplify the menus, by showing relevant links only to relevant users. E.g. staff see different links from students.
   • Improve the course icons by making them larger and clearer. E.g. the maximise block link is not intuitive.
   • Show alerts to users – e.g. explaining that editors can drag and drop files, warnings of Moodle outage periods.
   • Improve navigation, e.g. by enabling links to key areas that users expect.
   • Use high contrasting colours on a pale background that is easy to read for those with dyslexia (e.g. not white).
2. Changes to Moodle configuration.
   • Configure text editors so they encourage accessible content design. E.g. offering heading styles 3-5, removing the inclination for people to add heading 1 and 2 tags when these are used at higher levels within Moodle pages.
   • Enable global search (assuming this does not negatively impact performance).
   • Allow students and staff to personalise the interface by enabling courses to be moved up and down on the My Home page, hide and show blocks, maximise the screen or use a default width better for reading and dock blocks.
3. Enhanced Moodle features.
   A number of plugins to Moodle exist that make Moodle more usable and improve accessibility.
   • Implement and configure user tours to help users understand how to use Moodle and point to help with accessibility features.
   • Install the course checks plugin to help staff create an accessible Moodle course – e.g. checks for assignment due dates in past, courses not reset, broken links.
   • Implement a Moodle course site map so students can easily see what is available on a course on one page.
   • Enable importing content from Word, which some users find easier to edit within than Moodle.
   • Pilot the Blackboard Ally plugin to help in the creation of more accessible learning resources and course structures.
   • Install the Office 365 plugin to make it easier to author, organise and link or embed content into Moodle (coming to Moodle core in v3.3).
   • Enable staff to add icons to help signpost particular areas of their course and help people who prefer these visual cues, as opposed to having to read excessive text.
4. Improved training, staff development and support.
   • Develop a course for Moodle editors so they understand how to develop accessible Moodle resources and activities.
   • Develop an online course to explain how Assistive Technologies can be used with Moodle (e.g. regions for JAWS, browser plugins to show a reading ruler, change fonts to OpenDyslexi font, improve colour contrast).
5. Improved interfaces by proposing enhancements to Moodle HQ and iParadigms (who provide Turnitin).
   • Adequately signpost links showing (new window, document, external/internal etc) automatically.
   • Enable users to personalise their experience by allowing them to choose their own course format, set blocks to particular colours.
   • Improve assessment interfaces, such as the Moodle Assignment rubric functionality and display.
   • Flag new items on the Moodle course page (allow this to be enabled/disabled in user preferences).
   • Improve the Moodle calendar – e.g. size, reliance on colour, clicking month to access full screen.
   • Improve the discussion forums – e.g. showing the entire thread when replying, the accessibility of the email alerts it sends.
   • Fix Moodle heading tags.

The UCL Digital Education team, staff in Disability Support teams and staff from IT for IoE  are slowly working through each of these five strands to make improvements to virtual learning experiences at UCL for those with disabilities. Many of these improvements will also benefit other Moodle users, since accessibility cannot be considered in isolation from usability, so this means an enhanced user experience for everyone!

The Accessible Moodle project is looking at how UCL Moodle can be made more accessible for those with disabilities, with input from disabled students and staff. A number of recommendations have been developed to guide work on the project and address the concerns of the focus group participants.

In order for e-learning to be accessible to all students and staff, including those with disabilities, the pages and resources contained in the Virtual Learning Environment (VLE) need to be constructed in a way that is accessible. The rules for doing this are not always straight forward to implement, so I set out to determine how others are developing their websites to meet the needs of disabled users.

I analysed the websites of a number of leading UK government, charity and public broadcasting websites to obtain a clearer idea of how web accessibility standards can be applied in practice. These websites aspire to meet the needs of a large range of users, including those with disabilities. The websites I analysed are:

• Disability Rights UK: disabilityrightsuk.org
• Scope: scope.org.uk (covers support for mobility impairment, amongst others)
• Action on Hearing Loss: actiononhearingloss.org.uk
• Action for blind people (working with RNIB): actionforblindpeople.org.uk
• British Dyslexia Association (BDA): bdadyslexia.org.uk
• UK government: gov.uk
• British Broadcasting Corporation (BBC): bbc.co.uk
• St Martin in the Fields: stmartin-in-the-fields.org

I used the built in Chrome web page inspection functionality, and a number of browser plugins to help me determine how the web pages were constructed, including:

• WhatFont? for checking font, font size and line spacing.
• ColorZilla for checking colours.

The four main types of disability are:

• hearing loss;
• visual;
• cognitive and neurological; and
• mobility.

Each of the four main types of disability are considered by at least one charity website (most of which focus on supporting that particular disability). Five of the websites aim to be accessible to people with a range of disabilities more generally, in order not to exclude members of the public, and this is also true of the websites for specific disabilities, already mentioned.

At UCL, the majority of our disabled students have cognitive and mental health conditions (Dyslexia, Dyspraxia, Autism, long term depression etc.). However, it is important we consider all types of disability when looking at improving accessibility.

Meeting web accessibility standards

The World Wide Web Consortium (W3C) is an international community, led by Tim Berners Lee (father of the world wide web). The W3C runs the Web Accessibility Initiative (WAI) to develop “strategies, guidelines, and resources to help make the Web accessible to people with disabilities” (W3C).

Part of the WAI includes the Web Content Accessibility Guidelines (WCAG) 2.0, for making web content more accessible. These recommendations are split into three levels from A to AAA. Most websites attempt to adhere to WCAG Level AA standard, “because it is not possible to satisfy all Level AAA Success Criteria for some content” (W3C).

Another WAI guideline is known as Accessible Rich Internet Applications Suite (ARIA) and defines how to construct HTML and scripting languages that aid users of assistive technologies, like screen readers. Screen readers read websites aloud for those who are visually impaired or who have difficulty reading, such as people with dyslexia.

Finally, the WAI Authoring Tool Accessibility Guidelines (ATAG) documents how to make accessible content editors that produce accessible content.

Five of the eight websites analysed mentioned they aimed to adhere to W3C WCAG in their Accessibility statements. Most also specified meeting level AA, which aligns with the aims of the UCL Accessible Moodle project.

Many of the WCAG guidelines are written very broadly, recognising the ability for accessibility to be addressed in different ways. However, there are common practices which make it easier to adhere to these. WebAIM (Web Accessibility In Mind), which is a non-profit organisation connected to Utah State University’s Centre for Persons with Disabilities provides practical advice on how to apply W3C standards when developing websites.

My analysis of websites was led by questions I had around how to apply the WCAG 2.0 guidelines to develop a more accessible Moodle. This blog post summarises common practices used by UK websites interested in being accessible to a broad range of people with various disabilities.

The analysis is broken into the following key areas:

• Design
• Headings
• Skip links
• Access keys
• Accessibility toolbar
• Accessibility statement
• Paragraph v div tags
• Alternative text
• Site maps

Design

“Avoiding anything that draws a person’s attention away from the main content and using good design, such as color, white space, and simple presentation can help users focus on important content and functionality.” (WebAim). The designs on these eight websites are simple, with bright colours and plenty of white space around key elements, such as the main content and lists of news items.

Colours

Blue and white is a common colour scheme. Some websites, particularly those aimed at users with dyslexia and hearing loss, use a lot of bright, primary colours for different menus and areas of the page. This helps people distinguish between different areas of the website and make links between the menu items and the corresponding section they are in. The St Martin in the Field’s website allows users to override the coloured boxes with a simple dark grey background by choosing the ‘High contrast’ option in the accessibility toolbar at the top of the page.

Every website examined, except Scope, has an off-white background, to help reduce glare for those with dyslexia and certain visual impairments. Scope does, however, explain to users how to change text and background colours within their web browsers from their Accessibility statement.

Disability Rights UK also provides a toolbar that changes the default colour scheme (dark blue on an off-white background) with a choice of dark text on a light blue background, or a high contrast option, with light green and yellow text on a dark grey background.

Logo

All eight websites link from their logo to the homepage of the site. To confirm this is also common practice for UK Higher Education institutions’ Moodle installations, I also checked some of these (Bath, Cranfield and SOAS) and they too follow this protocol. Therefore, I suggest the UCL logo on UCL Moodle should link to the UCL Moodle homepage. This was raised by a student in one of the project focus groups, who expected this behaviour and were surprised that, in the current UCL Moodle, the logo does not link anywhere.

Links

Links were either underlined when there weren’t many links on the page; or coloured and usually bold, with an underlined hover state. Only the UK Government website underlined links in the menus. For most sites they did not, as this would have been overwhleming.

The links that were underlined normally, had a hover state with no underline. A few were coloured with no hover states, which may prove problematic for people with colour blindness.

In Moodle, there are links in close proximity to each other, both in the main content region and in side menus, so I suggest an approach where linked text has a unique colour and is bold, but only appears with an underline when someone hovers their mouse over it, to avoid visual clutter. However, it still needs to be clear to those who are colour blind that it is indeed a link, so it may be that links within textual content are underlined and links in blocks and alongside icons (such as the resources and activities), where it is more clear they are links, are not underlined. This causes inconsistency to the visual appearance of links, which may cause confusion, so it’s likely the project will need to go back to the disabled community to check what is best for most people.

Text

Most of the websites examined showed large text, at a minimum of 16px with line heights between 1.25 and 1.6. Although line-height is only included in the AAA level of the WCAG 2.0 standard and the Acessible Moodle project is aiming to adhere to AA level, the line height and paragraph spacing is a current issue that has been identified within UCL Moodle.

WCAG 2.0 AAA expects a way to set “line spacing (leading) [to] at least space-and-a-half within paragraphs, and paragraph spacing [to] at least 1.5 times larger than the line spacing.” (W3C). Therefore, the project will aim for the visual design to meet this requirement.

Icons

One UCL student mentioned they find it easier to recognise icons than links that are purely text. The British Dyslexia Association website makes extensive use of icons to supplement menu item text. Action on Hearing Loss also uses icons to highlight key areas of the page and to supplement call to action buttons. Icons are also common in popular social media websites like Facebook and LinkedIn, so it is likely a large number of UCL students will be familiar with using them to help them navigate. I suggest we use icons to supplement text links, and in some cases, such as the search, replace the text link entirely, taking care to provide adequate alternative text for people using screen readers. In addition, the icons that supplement text should be hidden from screen readers entirely, using techniques defined in the WAI-ARIA guidelines.

Headings

WebAim states that websites should generally only have one <h1> heading tag per page to describe the page title, followed for a <h2> tag the describe the section title.  Moodle already follows this convention.

Most of the websites widely use 3 or 4 heading tags, and have only 1 heading 1 (<h1>) tag to describe the title of the page. It is important these headings occur in order, to help blind users understand the navigation structure. Therefore the Atto text editor only allows Moodle course editors to add heading 3 to 5, as headings 1 and 2 already exist on a Moodle course page to describe the course name and section heading. If possible, the TinyMCE text editor should be configured to do likewise, otherwise content will jump incorrectly from one level to the next, as shown below:

• H1: page title
• H2: section title
• H1: content section (added by Moodle course editor who sees heading 1 as the obvious option for a “first” heading and is unaware of the existing heading 1 and 2 on the webpage).

The WAI ATAG guidelines for improving the accessibility of rich text editors are a useful reference here.

Skip links

Skip links are a common way “to bypass blocks of content that are repeated on multiple Web pages.” (W3C).

All but two of the websites use skip links to enable screen reader users to skip straight to the main content area. Most of these are hidden to sighted users, but two of the websites provide visible skip links at the top of the page. These same two websites also provide a skip to navigation or footer links, and one of them also enables users to skip to the accessibility statement.  Webaim suggests limiting the number of skip links in most cases, to avoid adding to the problem of too many links on a page. The skip links on Moodle only appear when a user presses the tab key. Webaim suggests this as a good way to avoid affecting the visual design of a website, while still catering to sighted keyboard users. The new theme provides a ‘skip to content’ link, which is warranted given the complexity of the pages.

Access keys

The majority of the websites analysed do not use access keys.

The Action on Hearing Loss website defines access keys on their accessibility page. These are based on the UK Government standard  and they describe how to use them (alt on Windows;  Ctrl on Mac, although each web browser may differ). Strangely, the UK gov website does not offer any access keys and the standard document on their website has now been archived, even though it seems a number of websites still refer to it and it appears to offer a default consistent schema for UK websites that still use access keys.

S – Skip to content

1 – Return to homepage

2 – News & events

3 – Sitemap

4 – Search site (at the top of the page)

6 – Help / contact

8 – Terms & conditions

9 – Feedback / contact us

0 – Access keys details

WebAim summarises that due to conflicts with browser and screen reader shortcuts, many web developers avoid the use of accesskeys, which explains the low number of websites I analysed that use them. This approach is now outdated and was removed from the WCAG standard when it was revised to version 2.0.

The Adaptable theme, which we will base the new UCL Moodle theme on, uses accesskey=”6″ for search (ALT+6 for Chrome), which does not match the UK government standard.  In most cases WebAim explains that browser accesskeys will be ignored and the shortcuts for assistive technologies like JAWS and web browsers will take precedence, so there does not seem much harm in leaving the accesskey in Moodle. Additionally, there is no impetus to create any further accesskeys for quick access to common features. Instead we should concentrate on upskilling screen reader users, and other users of assistive technologies, to better use the native features of their software and hardware.

Accessibility toolbar

Four of the websites provide some form of accessibility toolbar at the top of the page. Three of these provide a variety of 3 text sizes, which seems redundant given that people can simply zoom in and out directly from the browser using the menus or common shortcut keys (Ctrl/Cmd+ and Ctrl/Cmd-).

The British Dyslexia Society provides Recite.me access at the top of the screen if the user chooses to enable it, which reads aloud text, enables background and foreground colours to be changed and enables OpenDyslexi font amongst others to be displayed on the website, amongst other features.There is an open-source Assistive Technology bar (ATbar) that can eaaily be installed on websites, or by end-users, but I have found it problematic, as there seems to be no way to stop the speech once it has started. Even closing the toolbar does not stop the text being spoken aloud.

At UCL, the Disability Services teams work with individuals to install and configure software that performs many of these tasks, so I do not suggest we implement an accessibility toolbar within Moodle itself.

Accessibility statement

All of the website analysed have an accessibility statement of some kind which explains how the organisation attempts to meet the needs of those with disabilities and in most cases provides a way to raise accessibility concerns a user may have with the website.

Most of these are directly accessible at the top of the page (3), or in the footer links (3). The British Dyslexia Association requires users to search for their Accessible Communications statement, and the UK government website expects users to know their Accessibility information is in the help section, which is available from a link in the footer. The scope accessibility statement is the most comprehensive and I suggest we use this as a template for our own Moodle Accessibility statement.

Paragraph v div tags

All the websites analysed use <p> tags for paragraphs, rather than <div> tags, which is the correct way to use this semantic element according to the W3C. Moodle also uses <p> tags correctly, rather than <div> tags, in both the Atto and TinyMCE text editors.

Alternative text

According to W3C WCAG 2.0, images should include alternative (alt) text for any image that is not purely for decoration, so visually impaired users can understand what the image is for. A similar feature is the title tag, which is text that is often applied to links, to explain to sighted users where the link will take them if they click on it. Title tags can also supplement the alt tag on an image where you want that text to appear as a tool tip for sighted users (Penn State).

Five of the websites provided only an alt tag for their images, with no title tag that appears when you hover over the image.

The Action for Blind People website provide captions directly below the images in a paragraph tag and a blank alt tag for their images. Although the example on the W3C website suggests indicating in the alt text that the following paragraph contains text to explain the image, WebAim claim it is fine to use an empty alt tag and include text directly after the image instead. WebAim also suggest using blank alt tags for purely decorative images, so screen readers skip over them entirely. This practice is supported by the W3C amongst others (Penn State; AbilityNet; Oregon State University).

Site maps

One feature requested by a focus group participant during the Accessible Moodle project was to provide a site map of the course. There is a course format that offers this, but currently Moodle does not allow students to choose their own course formats, this can only be changed by the course editor.

Half of the websites analysed provide sitemaps and all but one spelt it as a single word. Since it is such a large site, the BBC website provides a separate site map for each area of the website. I suggest the project team raise the idea of allowing students to choose their own course formats and if this happens then investigate the sitemap course format. In addition, I suggest raising the idea of providing a site map to users to help them navigate each Moodle course.

Summary

So what does this mean for the development of a more Accessible UCL Moodle?

From my investigation of common practice across eight UK websites, I would suggest the following for the development of a more accessible UCL Moodle:

• UCL Moodle should use an off-white background in its content and menu areas.
• The UCL logo should link to the UCL Moodle homepage.
• Links should underline on hover to avoid visual clutter in Moodle courses, most of which contain many links.. The potentially exception to this is for the content areas, where it may be useful to indicate links with an underline to supplement the coloured text for those who can’t distinguish this colour difference. This is providing the inconsistency in behaviour between the list of links and the links within content does not prove confusing for the majority of users. This therefore, needs further thought and consultation.
• Text should be 16px for paragraphs, with a line height of 1.5 (times the normal spacing) and paragraphs another 1.5 times larger than the line spacing.
  • Icons should supplement text links and in some cases replace the text entirely where the icon easily recognised as performing a particular function (such as the search icon). Icons need alternative text where replacing text and need to use ARIA tags to hide them from screen readers, where supplementing text.
• The TinyMCE editor should be configured to only show headings 3-5, to ensure a clear page structure for screen-reader users.
• Access keys should not be used as this is an outdated accessibility feature that is mostly overwritten by browser and assistive technology shortcut keys.
• We should teach assistive technology users to use the shortcuts native to the software.
• An Accessibility toolbar (like ATBar) is not required due to the availability of assistive technologies for those who need it, especially since it does not allow text to speech to be paused and resumed.
• An Accessiblity statement should be available, either in the header or footer, containing similar information to what is provided on the Scope Accessibility webpage.
• Alternative text should be used for all images portraying information, or that are used as a link.  Any images where a tooltip would be useful, such as icons to explain their meaning, should also include a title tag. Purely decorative images should have an empty alt tag, so screen readers skip over them, which simplifies navigation of the page.
• The project should raise the idea of making a sitemap available for each Moodle course to the Moodle development community, to enable students to easily locate resources and activities on the page.

Read the top 10 easy accessibility tips from WebAim for further tips on making your website more accessible.

The UK Open University (2006) provide a useful introductory course, called Accessibility of eLearning, that will help you understand how to create accessible e-learning experiences that provide access for all. The course can be completed online, or downloaded in a number of common file formats, including for e-readers and as a PDF.

I would strongly suggest either completing the course, or reading the course materials, but if you don’t have time I’m going to summarise the key points in this post:

1. In 2006, disability affected 10-20% of every country’s population, and this number is growing.
2. In 2006, 15% of the UK population, over 16 years old, self-declared a disability.
3. A disabled person is one who has a mental or physical disability that has a substantial, long term (12 months or more), adverse effect on their ability to carry out normal day-to-day activities.
4. Around 1 in 10 men and 1 in 200 women have red-green colour blindness.
5. UK Universities are legally obligated to make reasonable, anticipatory adjustments to ensure those with disabilities are not discriminated against.
6. There are two views of disability. The medical model describes the problem of disability as stemming from the person’s physical or mental limitation. The social model sees disability as society restricting those with impairments in the form of prejudice, inaccessible design, policies of exclusion, etc.
7. Accessibility is about both technical and usable access for people with disabilities. For example, although a table of data may be technically accessible by a blind person using a screen reader, they may not be able to relate the data in each cell to its column or row heading, so the meaning of the data is lost in the process, rendering the table unusable for that person.
8. Computers enable even severely disabled people to communicate unaided, giving them independence and privacy that is not possible when they need to rely on human assistants.
9. When communicating online, a disability may not be visible, removing barriers caused by people’s reactions to the disability.
10. Creating accessible learning environments helps everyone, not just those with disabilities. For example, products that can be used by blind people are also useful for people whose eyes are busy*.

*This last point reflects my own preference for listening to academic papers while running or walking to work, when I would be otherwise unable to “read” the paper. As a student and full-time employee, being able to use this time to study enables me to manage my time effectively and merge my fitness routine, with study time. This is only possible because my lecturers, and many journals these days too, provide accessible documents that can be read out loud using my mobile smartphone.

This list brifly summarises the key points I drew from the OU’s Accessibility of eLearning course and demonstrates some of the ways we, as developers of online courses, can make better online learning experiences for all our students, including those with disabilities.

References

Open University (2016) Accessibility of E-Learning. [Online]. Available from: http://www.open.edu/openlearn/education/professional-development-education/accessibility-elearning/content-section-0 [Accessed: 13 June 2017].

Please see info below for details:

Thank you for being a valued member of the GW Micro and Window-Eyes family. We regret to announce that sales of Window-Eyes have ended in the United States and Canada. Users outside of the United States and Canada should contact their local distributor for options. We are committed to our customers and will honor existing product purchases and software maintenance agreements, and we will continue to provide technical support to end users that have purchased Window-Eyes or a support package.

All users who are currently using Window-Eyes can continue to use the software indefinitely; however, as the Windows(r) operating system and/or applications change over time, Window-Eyes may not function adequately for your needs.

We understand how important a screen reader is to you and are offering

• JAWS(r) for Windows 18 as a replacement.  We are committed to providing a smooth transition and will honor existing Window-Eyes product purchases and software maintenance agreements (SMA), as follows.
• End users that paid for and are current with Window-Eyes 9.x will be converted to JAWS 18 at no charge.
• If you are using an earlier version of Window-Eyes, you can purchase an upgrade to JAWS 18.
• If you are using the free version of Window-Eyes you cancontinue to use it. While there is not an upgrade path from the free version, if you are interested in purchasing JAWS, please contact our sales team at 800-444-4443.
• Existing Window-Eyes SMAs will be rolled into the JAWS SMA program for end users that migrate to JAWS.

Learn more about the migration options and pricing.

To make this process as easy as possible, we ask you to complete a simple web form that will go directly to our sales team, who will then contact you with an authorization code for JAWS 18, or request additional information if necessary.

Requests for upgrades must be submitted using this migration form, or by phone at 800-444-4443 by July 31, 2017.

Note, the free Window-Eyes Offer for Users of Microsoft Office version is not part of the conversion program.

If you have any questions please call us at 800-444-4443 or email us at orders@vfogroup.com.

 

UCL staff from Digital Education Advisory and UCL’s Disability Services teams are currently looking at how to improve the accessibility of UCL Moodle for those with disabilities, which will benefit all users. Information from two focus groups, one with students and one with staff, have highlighted a number of concerns, which the Accessible Moodle project aims to address.

The focus groups identified ten areas of concern (listed in order of priority):

• Clutter – it is difficult to find what you are looking for amongst irrelevant links and content.
• Emphasis – understanding what is the most important information is not easy.
• Layout – page elements are not configurable, there is too much visible at once and the blocks are too wide.
• Navigation and Orientation – pages are long and disorganised, with links to external services not adequately signposted.
• Usability – some interfaces, especially for assessments, are particularly difficult to use.
• Awareness – useful features (skip links) and services (Moodle snapshot) remain unknown to those who would benefit from them.
• Personalisation – there’s a lack of configurable page elements (blocks, fonts, font sizes and colours) or information about how to do this independently with browser plugins and other assistive technologies.
• Text – there’s a lot of overly long text that is too small, in a difficult to read font with poor contrast and in difficult formats both in Moodle and the resources it contains.
• Consistency – there’s inconsistencies between some Moodle courses and conversely some courses not being adequately distinguishable from others.
• Graphics – there’s heavy reliance of written information that could be expressed more simply with icons and images, with appropriate alternative text for those using screen readers.

The learning curve of using new interfaces, problems with assessment, and clunky mobile access were also mentioned by the focus group participants.

These issues will be addressed by a number of initiatives:

• A new, more accessible UCL Moodle theme for use on desktop and mobile devices.
• Changes to Moodle configuration.
• Enhanced Moodle features.
• Improved training, staff development and support.
• Proposals to Moodle HQ and iParadigms (who provide Turnitin) to improve interfaces.

Further updates on this project will follow on the Digital Education blog.

The Digital Education Advisor for BEAMS, Jess Gramp, worked with the E-Learning Champion for Science and Technology Studies (STS), Christina Ogunwumiju, to develop a Moodle course template that meets the UCL E-Learning Baseline 2016.

Christina then applied this baseline to every Moodle course in the department using the Moodle import feature. This means students now have a more consistent experience across modules. They can now easily find their learning resources and activities because they appear in common sections across their Moodle courses.

Jess developed a guidance document for staff, to show them how to meet the baseline when using the template. Complying with the list of items on the template guide (which only number 18) is a lot quicker than having to make decisions about how to adhere to all 30 items on the the entire baseline checklist, without the guidance of template text.

You can view and download the template guidance document below. If it doesn’t load, please refresh this page.

 

If you would like to develop a Moodle template to improve consistency in your own department, please contact Digital Education at digi-ed@ucl.a.uk.