Thurs 28th – Fri 29th June

Hosted by Birkbeck, University of London

Following the University of London’s successful conference Demystifying User Experience Design & Testing last year, the Bloomsbury Learning Environment (BLE) in partnership with the University of London (UoL) is holding a free, two-day event for staff based at UoL member institutions on Thursday 28th and Friday 29th June.

On these two days, we are offering three distinct workshops, which are each focused on different applications of UX. Come along to all three or select those that interest you. Places are limited, so don’t delay registering your place!

Day 1: Thursday 28th June

am: User Research: focus groups, user testing and user feedback
pm: User Centred Content

Thursday 28th June: Morning workshop

User Research: focus groups, user testing, surveys and user feedback

A practical session with guest speakers sharing their insights into user research and associated applications.
Led by Naomi Bain, Web Officer (Training and User Experience) – Birkbeck, University of London

0930 Coffee & Registration
• Introduction (Naomi Bain)
• Keynote: conducting f2f user testing (Jane Lessiter, Goldsmiths)
• Case studies: sharing experiences of user research
• Practical session: how to conduct a web user testing session. This session will include tips, discussion, sharing experiences, questions and trying out the roles of tester and testee (Naomi)
End by 1300

Thursday 28th June: Afternoon workshop

User Centred Content

An overview of the online tools available to help you to plan and review your own content. Mapping users against online content – bring along a piece of your own content to review! Finishing with a panel Q&A discussion around content strategy and governance.
Led by Melanie Read, Head of Digital – University of London

1345 Registration, with a prompt start at 1400
• Welcome, Introductions and icebreaker
• Content planning – what tools do you use for planning content.
• Content mapping – against the difference users types and then creating content suitable to that user.
• Content strategy and governance
• Panel discussion: how to manage governance
End by 1630

Day 2: Friday 29th June

am: Moodle and Accessibility

Friday 29th June: Morning workshop

Moodle and Accessibility

This workshop will focus specifically on Moodle and the considerations and requirements to ensure courses are accessible to all users.
Led by Sarah Sherman, Service Manager – Bloomsbury Learning Environment

0930 Coffee and registration
• Welcome & Introductions (Sarah Sherman, BLE)
• Presentation 1: Birkbeck For All (Leo Havemann, Birkbeck)
• Presentation 2: Policy for Accessibility (Nic Charlton, University of London)
• Presentation 3: Working with Moodle (Nic Christodoulou, SOAS)
• Presentation 4: Accessibility initiatives at UCL (Jess Gramp & Paul Thompson, UCL)
• Presentation 5: Checking for accessibility in Moodle (Herve Didiot-Cook, Blackboard)
• Panel discussion
• Workshop activity: developing Moodle accessibility guidelines for practitioners
End by 1300

Book your place now.

For further details about the event, please contact Sarah Sherman or Melanie Read

As part of a wider Accessible Moodle project, a new UCL Moodle theme is being designed to make it more accessible for those with disabilities. The theme is like a skin (or a wallpaper) that changes the way the text and colours are displayed, without changing any of the content that exists on each Moodle page. As well as changing the look and feel of all Moodle pages, it will provide additional navigation aids in the form of menus, blocks that can be hidden and potentially also docked blocks, which sit to the left of the page for easy access.

The new theme will be rolled out to all staff and students in the next major upgrade of UCL Moodle in summer 2018. The Moodle theme is applied to a user account and in Summer 2018 everyone will be switched to the new theme automatically as part of the UCL Moodle Summer Upgrade. The theme is not to be confused with Moodle course formats, which allow you to change the way a Moodle course is laid out.

I wrote earlier on how the new theme will address accessibility issues. A number of staff across UCL provided feedback on the proposed theme and after a number if iterations, we have now agreed on a design that foremost meets the needs of staff with particular disabilities, as well as being more usable for everyone. As well as working with individuals who participated in the project’s initial focus groups, the E-Learning Champions were also given the opportunity to feed in their comments on the proposed theme and forward this to interested colleagues.

The proposed new UCL Moodle theme showing collapsed topics format. Click to enlarge.

We had contemplated a pink theme, however, blue proved to be a better option for a number of staff with particular disabilities. The blue version was also more popular with those staff without disabilities. The below design shows how the tabbed course format will look, but with blue, instead of pink tabs, menus and links.

Tabbed course format but the pink tabs, menus and links will be blue. Click to enlarge.

The UCL Moodle homepage will be simplified and will provide more space for news relating to teaching and learning at UCL. The menus will be blue instead of the pink shown in the design below.

UCL Moodle homepage, but with blue instead of pink menus. Click to enlarge.

The Accessible Moodle project team at UCL worked closely with designer Ralph Bartholomew from St Albans Web Design and developer Pat Lockley from Pgogy Webstuff to implement the new theme.

If you have any questions or comments about the new theme, or would like to be involved in the pilot, please contact Jessica Gramp.

[Edited to remove reference to the theme pilot, which was not able to go ahead as planned].

To learn more, click on one of the Guidelines in the boxes below.

UDL Principle 1 aims to ‘provide multiple means of representation’  by ‘providing options for perception’, which includes ‘offer[ing] ways of customizing the display of information’ (CAST 2011). This means the VLE should offer the ability to do things like resize text and enable screen-readers to read aloud text to those who have visual impairments or dyslexia.

As part of a wider Accessible Moodle project, a new UCL Moodle theme is being designed to make it more accessible for those with particular disabilities.

The new theme will address some accessibility concerns by using:
• Larger fonts and icons.
• Off-white backgrounds to reduce glare.
• High contrasting and brighter colours.
• Making the main content areas more prominent.
• Using icons, alongside or in place of text, to de-clutter the screen and make it easier to identify important links and information.

If you work or study at UCL and would like to provide feedback on the initial designs, please contact j.gramp@ucl.ac.uk as soon as possible, using your UCL email account.

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.