Or use a single-sign-on provider

Skip to main content

Accessibility Statement for Direct Application Service

This website is run by Manchester Metropolitan University. We want as many people as possible to be able to use this website. For example, that means you should be able to:

  • change colours, contrast levels and fonts
  • zoom in up to 300% without the text spilling off the screen
  • navigate most of the website using just a keyboard
  • navigate most of the website using speech recognition software
  • listen to most of the website using a screen reader (including the most recent versions of JAWS, NVDA and VoiceOver)

We’ve also made the website text as simple as possible to understand.

AbilityNet has advice on making your device easier to use if you have a disability.

How accessible this website is

We know some parts of this website are not fully accessible:

  • some pages and online forms are difficult to navigate using just a keyboard
  • some components throughout the site are not keyboard accessible
  • you cannot skip to the main content when using a screen reader
  • the colour contrast of some text and components is poor for low vision users
  • forms are not labelled correctly so can be difficult to complete when using a screen reader
  • some documents are not fully accessible to screen reader software

What to do if you cannot access parts of this website

If you need information on this website in a different format like accessible PDF, large print, easy read, audio recording or braille you can contact us in the following ways:

We will forward your message to the appropriate member of staff and get back to you as soon as possible.

Reporting accessibility problems with this website

We’re always looking to improve the accessibility of this website. If you find any problems not listed on this page or think we’re not meeting accessibility requirements, contact: digital-accessibility@mmu.ac.uk. Your message will be forwarded to the relevant team who will get back to you as soon as possible.

Enforcement procedure

The Equality and Human Rights Commission (EHRC) is responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (the ‘accessibility regulations’). If you’re not happy with how we respond to your complaint, contact the Equality Advisory and Support Service (EASS).

Contacting us by phone or visiting us in person

If you wish to speak to someone by phone or visit us in person in relation to an accessibility issue covered in the Accessibility regulations you can:

  • Call or drop in to any of our on campus students hubs in the Business School, Geoffrey Manton Building and the Brooks Buildings. Staff at the student hubs will be able to give direct advice on most issues but in some cases will refer you colleagues with specific accessibility responsibilities.
  • Visit our IT Helpline support desk 12:30pm-4:30pm, Monday to Friday, Ground Floor, All Saints Library, All Saints Park, Manchester, M15 6BX.

If you require any specific support for your visit e.g. a British Sign Language (BSL) interpreter please contact our helpline and they will liaise with colleagues in our Disability Support Team to arrange this.

If you can’t view the map on our contact us page, email or call us for directions.

Technical information about this website’s accessibility

Manchester Metropolitan University is committed to making this service accessible, in accordance with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

This website is partially compliant with the Web Content Accessibility Guidelines version 2.1 AA standard, due to the non-compliances listed below.

Non accessible content

The content listed below is non-accessible for the following reasons.

Non compliance with the accessibility regulations

Structure

Some pages feature headings which does not appear in a logical order, (for example, content that is dependent on the previous heading at level 4 might have a heading at level 2), which to a non-sighted user would give the impression that the content is not related. This fails WCAG 2.1 success criterion 1.3.1 (Info and Relationships) and 2.4.6 (Headings and Labels).

Some pages feature content as a list of items but the list mark-up used is incorrect. Without the correct list mark-up the content for non-sighted users can read like a string of text that might not make sense. This fails WCAG 2.1 success criterion 1.3.1 (Info and Relationships).

Some pages feature interactive elements (buttons, links, form inputs) marked up using neutral mark-up such as a <div> or <span> element, which affects users of assistive technology who rely on semantic elements that convey meaning or how they should be used. This fails WCAG 2.1 success criterion 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value).

Some pages feature label elements used outside of a form or to provide structure in a non-standard way. This fails WCAG 2.1 success criterion 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value).

Landmarks are not used correctly making it difficult for users of assistive technology to easily identify the purpose of page content and quickly traverse the page. This fails WCAG 2.1 success criterion 1.3.1 (Info and Relationships).

Some page content is formatted using HTML instead of CSS. This fails WCAG 2.1 success criterion 1.3.1 (Info and Relationships).

Forms

In some cases form fields are not associated with text labels therefore screen reader users may have some difficulties completing a form. This fails WCAG 2.1 success criterion 1.3.1 (Info and Relationships), 2.4.6 (Headings and Labels) and 3.3.2 (Labels or Instructions).

On some pages related form fields are not grouped together so the user knows they are making a relative choice. This fails WCAG 2.1 success criterion 1.3.1 (Info and Relationships), 3.3.2 (Labels or Instructions) and 4.1.2 (Name, Role, Value).

Some pages have forms fields that have not been associated with a purpose relating to the expected content of the field, making it difficult for users to use autofill features. This fails WCAG 2.1 success criterion 1.3.1 (Info and Relationships) and 1.3.5 (Identify Input Purpose).

Form fields that require a response from the user aren’t clearly marked using programmatic information. As a result, some assistive technology users may not be aware they are required to complete a field and this can result in a form error. Users may be confused about why the completed form is not being accepted. This fails WCAG 2.1 success criterion 3.3.2 (Labels or Instructions).

Some form fields have no text label or the meaning of the field is ambiguous. This fails WCAG 2.1 success criterion 1.3.1 (Info and Relationships), 2.4.6 (Headings and Labels) and 3.3.2 (Labels or Instructions).

Instructions for completing some form elements are marked-up inappropriately and are not accessible to users. This fails WCAG 2.1 success criterion 1.3.1 (Info and Relationships) and 3.3.2 (Labels or Instructions).

Error handling

It is difficult for non-sighted users to identify which form elements have an error when submitting a form. This fails WCAG 2.1 success criterion 3.3.1 (Error Identification), 3.3.2 (Labels or Instructions) and 3.3.3 (Error Suggestion).

Sensory dependency

Some information is being conveyed on pages using only colour. This fails WCAG 2.1 success criterion 1.4.1 (Use of Color).

Some links are visually distinguishable using colour alone. This fails WCAG 2.1 success criterion 1.4.1 (Use of Color).

Some links are not visually distinct. This fails WCAG 2.1 success criterion 1.4.1 (Use of Color).

Dynamic changes to page content are not being conveyed to assistive technologies as the user interacts with the page. This fails WCAG 2.1 success criterion 1.3.3 (Sensory Characteristics) and 4.1.3 (Status Messages).

Contrast

Colour contrast of some text is insufficient for users with low vision. This fails WCAG 2.1 success criterion 1.4.3 (Contrast (Minimum)).

Colour contrast across borders of interactive elements (e.g. inputs and buttons) is insufficient for users with low vision. This fails WCAG 2.1 success criterion 1.4.11 (Non-text Contrast).

Colour contrast on some UI elements is insufficient for users with low vision. This fails WCAG 2.1 success criterion 1.4.11 (Non-text Contrast).

Resize text

When text size is increased by 200% some content is lost or obscured. This fails WCAG 2.1 success criterion 1.4.4 (Resize text).

Keyboard and Focus

Some items within content are not keyboard accessible and require a pointing device such as a mouse. This fails WCAG 2.1 success criterion 2.1.1 (Keyboard).

Some items on pages cause a keyboard trap. This means keyboard-only users can’t move past the content using the keyboard alone. This fails WCAG 2.1 success criterion 2.1.2 (No Keyboard Trap).

It is not possible for keyboard-only users to track all the components on the page due to lack of indication of focus. This fails WCAG 2.1 success criterion 2.4.7 (Focus Visible).

Navigation

It is not possible to skip repeating blocks of content (such as navigation) present across multiple pages. This fails WCAG 2.1 success criterion 2.4.1 (Bypass Blocks).

Some pages do not have adequately descriptive titles. There is more than one page on the website that has the same title. This fails WCAG 2.1 success criterion 2.4.2 (Page Titled).

Order

Some of the content on pages does not have the correct read order. This fails WCAG 2.1 success criterion 1.3.2 (Meaningful Sequence).

The focus order of some form components is not always in a logical order. This fails WCAG 2.1 success criterion 2.4.3 (Focus Order).

Links and Buttons

Link text on some pages is not descriptive of the destination page or could be improved by including context. This fails WCAG 2.1 success criterion 2.4.4 (Link Purpose (In Context)).

On some pages the purpose of buttons is presented using visual elements alone and no text alternative is provided. On other pages buttons have ambiguous text where the context must be assumed or gathered by the user. This fails WCAG 2.1 success criterion 2.4.4 (Link Purpose (In Context)) and 4.1.2 (Name, Role, Value).

Some links invoke a change of context (e.g. opening a new tab or window) but do not inform the user in advance. This fails WCAG 2.1 success criterion 2.4.4 (Link Purpose (In Context)).

Parsing

The code of some of pages contains errors which may cause the page to read incorrectly or not as intended. This fails WCAG 2.1 success criterion 4.1.1 (Parsing).

Name, role and value

Expanding controls don’t have the appropriate features that make it accessible to people who use screen readers. This fails WCAG 2.1 success criterion 4.1.2 (Name, Role, Value).

Scripted page elements (e.g. help icons for input fields) don’t have appropriate Name, Role, or Value. This lack of information will make the components ambiguous to users. This fails WCAG 2.1 success criterion 4.1.2 (Name, Role, Value).

Progress information or the number of steps required is not available or made clear to all users. This fails WCAG 2.1 success criterion 4.1.2 (Name, Role, Value) and 1.3.1 (Info and Relationships). 

Content that’s not within the scope of the accessibility regulations

PDFs and other documents

Many of our older PDFs and Word documents do not meet accessibility standards – for example, they may not be structured so they’re accessible to a screen reader. This does not meet WCAG 2.1 success criterion 4.1.2 (name, role value).

Some of our PDFs and Word documents are essential to providing our services. For example, we have PDFs with information on how users can access our services, and forms published as Word documents. By September 2020, we plan to either fix these or replace them with accessible HTML pages.

The accessibility regulations do not require us to fix PDFs or other documents published before 23 September 2018 if they’re not essential to providing our services.

Any new PDFs or Word documents we publish will meet accessibility standards.

How we tested this website

This website was last tested on 10th June 2019. The test was carried out by nFocus Testing.

An audit was conducted on all pages and these were checked for all AA non-conformances. The audit process consisted of a detailed page-by-page analysis of all the pages to ensure that all non-conformances are detected. A combination of browser tools, assistive technologies such as screen readers, and code inspection to test the site against WCAG requirements were used.

We tested:

The Direct Application Service available at https://sm-portal-mmu.thesiscloud.com

This statement was prepared on 23/10/20. It was last updated on 23/10/20.

If you have any questions about using this service you can email us