Exercise steps and external tools criteria

Content is served over SSL/HTTPS. 

We enforce this in Course Creator.

Includes all assets used and any paths accessed via AJAX. 

This ensures that our learners will not experience any security warnings in their browser.

An easy way to check this is to look at the URL for the tool, it should begin HTTPS. 

It should not be possible for the learner to cause an error or bad state through usual or unusual usage. Inputs are especially vulnerable and exercises must sensibly handle illegal entries (e.g. characters in a number input). Many HTML5 validations such as numeric input will not work on older browsers so cannot be relied upon.

Content is served in an iFrame hosted on futurelearn.com with no framebusting.

What is framebusting?

Have you made sure not to use any framebusting code?

Content is not acting purely as a data collection tool and does not request or attempt to capture personal information about learners.

Includes the collection of personal data already provided by learners on their FutureLearn profile. 

Tools should never require the learner to register or login.

Test all possible learner journeys - likely and unlikely - thoroughly to ensure no login is required at any stage and they are stable. 

It is highly recommended that a testing framework and methodology be used such as BDD/TDD. This will allow for broad and reproducible test coverage to alert you of regressions as you develop.

Deliver essential course content, to meet core learning outcome(s) without recreating existing platform functionality. 

The learner experience must remain consistent. If learners are taken to tools that have their own commenting or functionality that directly conflicts how FutureLearn works, this causes confusion. 

They should represent significant added value for learners which repays the development effort required of the partner and FutureLearn.  

Embedding video into Exercises. FutureLearn controls its core video infrastructure & player to ensure consistent service, compatibility and accessibility to all users. Embedding video from other sources can result in these commitments not being met (e.g. mobile-support or lack of subtitling).

Familiarise yourself with our existing step types. 

Is the purpose of your activity mainly text-based? Add a discussion step instead for a smooth and accessible learner experience.

Contain minimal internal navigation links or feature links that take the learner out of the platform

Any navigation within the exercise itself should be presented in such a way that it cannot be confused with the main FutureLearn step navigation.

If navigation takes them out of the step altogether, learners are unlikely to return.  

Not used for summative assessment. 

Engagement data (e.g. a learner’s score) cannot be written back to the FutureLearn application

Partner branding is not present within the iFrame

All third-party media is embedded with the rights to reproduce within FutureLearn. 

We do not check this for each Exercise Step, it is the partners responsibility to maintain all rights and copyright. 

The tool/step can be experienced even with Javascript disabled.

In the absence of correct document headers, older versions of Internet Explorer will interpret web pages in “Quirks Mode”. This may cause issues in handling CSS & JavaScript. 

Another issue is a blank screen appearing when JavaScript is disabled. See exercise step further guidance for what to do if a blank screen is appearing. 

Explain any limitations to your exercise step clearly to learners and offer fallbacks for those who are unable to access the resource. Some courses have used walk-through videos to both help instruct learners in using the exercise. 

Hit areas and behaviours cannot be confused with native UI elements. 

For instance, be careful when implementing swiping. On iOS swiping is used as the back button in the default browser. Be careful adding elements to the bottom of the screen on iOS where they may trigger the Control Center. 

The recommended range of the target for hit areas on mobile is 7-10mm. (See the BBC mobile accessibility guidelines for touch targets). These are for mobile app development but the principles are the same given the smaller screen size.

The types of user input expected can also be tailored towards multi-platform use.

Setting current ‘type’ attributes on inputs will display appropriate keyboards on mobile devices. Mandatory keyboard shortcuts should be avoided where possible, with touch-compatible alternatives made available.

Are all hit areas on mobile larger than 7-10mm?

No media queries on IE8 causing strange layout presentation. IE8 does not respond to media-queries in CSS which prevents many approaches to responsiveness. This can be easily polyfilled with Respond.

Inability to scroll on iOS devices. The iframe in which exercises are embedded assumes that they operate in a ‘full-screen’ state. See CSS rules within further exercise step guidance, if you require scrolling. 

Requiring keyboard interaction. Learners accessing the exercise on mobile or tablet platforms will not be able to interact this way.

Content does not flow outside the screen size by default.

Content will be forced to fit the full width and height of the device (for exercise steps) with no scrolling and a 75px FutureLearn header. If your content is required to scroll we recommend using a third party library or implementing it in your own CSS.

This may be achieved through either proportional scaling, or through breakpoints at which the layout adapts. Existing CSS frameworks such as Bootstrap can help in implementing this.

Have you implemented scrolling if you need it? 

L

Fully navigable and usable through just keyboard (tab, arrow and enter keys), in addition to mouse, and touch. This includes having clear visual indications of focus.

Common issues include: 

Illogical tab order, which can happen due to tab index attributes with values greater than 0. This upsets the natural order of the page and is confusing for screen-readers. If you need to set the tab index value on any elements, please only use values of 0 or -1. Find out more. 

Using HTML elements other than button, a etc. as click targets will result in keyboard uses being unable to select and interact them.

Due to their graphic nature, canvas tags do not expose their contents to browser accessibility systems. When it is necessary to use canvas, important labels should be present in the main DOM.

Keyboard accessibility can be tested simply by running through all possible user journeys using the keyboard (e.g. tabbing between elements and using enter to trigger actions). See exercise step further guidance for what to do if you have an illogical tab order. 

When tabbing through the exercise, the focused element/control should always be clear. FutureLearn generally displays a one-pixel blue (#0000FF) border to indicate this state.

Browser extensions can automate some aspects of accessibility auditing for example Google Chrome’s Accessibility Developer Tools and Color Contrast Analyser but many aspects require manually testing. 

M

All text elements are a minimum of 14px for standard text, and 18px for large text, regardless of physical screen size.

There must be a minimum of 4:5:1 contrast ratio for standard text, and 3:1 for large text.

N

Fully functional and presented without compromise on different screen sizes, device classes, and orientations.

Available iin line with our browser support matrix. See minimum resolutions below.

Test on a range of actual devices, across both Android and iOS platforms Emulating these by changing the window size is not sufficient. At the very least test on Chrome, Firefox, Microsoft Edge and Internet Explorer. Services such as Browserstack can be used to undertake this without installing and maintaining multiple browser versions. Our browser version requirements indicate the range of desktop browsers that exercises are expected to function on.

In exceptional circumstances, where the content is not well suited to mobile devices or it is impossible to meet accessibility standards or support a certain browser/device, FutureLearn will ask you to insert an advisory message to mobile users. 

All exercises should be tested in a full range of presentations, devices and browsers to ensure it behaves and is presented as intended. 

Can you view or scroll to all of the content on these actual devices (avoid only changing window size): 

A small screen (e.g. a smartphone) in landscape and portrait mode, including the transition between these.

A medium screen (e.g. a tablet) in landscape and portrait mode, including the transition between these.

A large screen (e.g. a laptop or desktop computer)

O

Text-based alternatives (accessible fallbacks) are provided where content does not meet these accessibility criteria.

If the exercise is not supported by all browsers or technologies.  If Javascript is required. 

Explain the fallback measure in the step content. 

For some steps, learners won’t be able to share their views to add to the fallback. But learners with visual impairments etc. can at least see some learner contributions. 

Add an accessible PDF document to the step, containing all the content in the tool (questions, feedback). 

Include clear instructions encouraging learners to write good titles and captions for their content uploaded to tools, for learners using screen readers. 

Width (px)

320

480

320

405

Height (px)

480

320

405

320