MAUVE++ Updates

  • Version 2.3.3 - Release Date 2022-06-21

    Within WCAG 2.1 guidelines, techniques may be defined in multiple Success Criteria.We updated our WCAG 2.1 implementation in order to associate the following techniques to all related Success Criteria:

    • SC 1.2.3 - H96
    • SC 1.3.1 - ARIA11
    • SC 1.4.3 - G145
    • SC 1.4.4 - SCR34
    • SC 1.4.8 - SCR34
    • SC 2.4.1 - ARIA11
    • SC 2.4.4 - F89
    • SC 2.4.7 - G195
    • SC 2.4.9 - H33
    • SC 4.1.2 - F89
  • Version 2.3.2 - Release Date 2022-05-11

    Updated technique F78 considering only outline-color to check whether the focus is visible

    Updated technique H98 added the 'off' value to the list of allowed values for all the input element types.

  • Version 2.3.1 - Release Date 2022-05-09

    Added the value REM to the allowed values for the following thechniques: C12-C13-C14-C28

    Updated techniques H30 and H65 in order to check whether the link or button description is contained also within descendant elements (in the previous version the description was only checked within text part of the analysed element

    Several users reported that the validator returns error for element that are not visible to users but they are accessible to assistive technologies such as screen readers. Such elements in bootstrap have the following class (Bootstrap 4:sr-only, sr-only-focusable; Bootstrap 5: visually-hidden and visually-hidden-focusable), we decided to skip the analysis of visual requirements (i.e. contrast between background and text color) for all elements having such classes

    Updated the evaluation summary overview by presenting the violated/warning/passed/not_applicable techiques listed by conformance level

  • Version 2.3 - Release Date 2022-04-20

    The implementation of the following thechniques has been updated:

    • G18: Understanding Minimum Contrast.
      The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following
      • Large-scale text and images of large-scale text have a contrast ratio of at least 3:1
      • Contrast between text color and background color > 4.5 and font weight bold and font size > (18.5px || 14pt)
      • Contrast between text color and background color > 4.5 and font weight != bold e font size > (24px || 18pt)
    • C38: The goal of this technique is to present labels and inputs in order to avoid horizontal scrolling. When the viewport space is limited and the inputs and labels cannot sit next to each other then they must be modified so that they are under one another (vertical alignment); this can be achieved by setting the display: flex property on form element or on div elements contained within a form.
    • G195: Managed both the hover and focus pseudoclasses and check the border-color (top, bottom, left, right) and outline-color properties. Added the control to check whether the contrast is not at least 3 then it checks that the border (or outline) is> = 2.
      Applied to input type text, button, color, date,email, file, month, number, password, reset, search, submit,tel, time, url, week; button and a elements.
    • G195: Added the 'off' value to the list of allowed values. Fixed a bug in the technique evaluation.
    • H65: We have modified the implementation of the technique control so that it does not return an error if the button element contains some text inside it (since several screenreaders correctly associate the text with the button role). If there was no text inside the button, then there must be a "title" and/or "aria-label" attribute
    • F30: The validator, in the previous version, checked all images contained within an <a> element and returned an error if the alt attribute was null / empty string. Currently it is becoming common practice to associate the empty alt attribute with decorative images and in this case the validator must not return an error; in this regard, in the new version, we have excluded decorative images from checking the alt attribute (attribute role = "presentation").
    • H30: In the validation of the H30 technique if a link does not have a text describing its scope than the validator checks whether the link has title or aria-label attribute. Regarding the images with empty alt attribute and contained within a <a> element, two additional checks have been added: one checks that the parent link element has the title attribute and the second checks that the parent link contains text inside it; if one of the two cases occurs, the validator does not return an error.
    • F78: Fixed a bug in the technique evaluation: it was checked the <link> element istead of <a>, input and button elements.
    • C28: Fixed a bug in the technique evaluation: in the new version we exclude the input type hidden elements.
    • SCR34: Specified the list of element that must be checked (div, input, span, p, textarea, section, table, form)
  • Version 2.2 - Release Date 2022-01-31

    The new version 2.2 allows users to create projects (set of pages to validate), and to schedule periodical audits, and visualize how the validation results change over time.

    Added to the evaluation report the Not Applicable category: it reports the number of techniques that are not applicable to the evaluated page elements.

    The accessibility and completeness metrics have been updated in their calculation, now they no longer consider not applicable techniques.

  • Version 2.1 - Release Date 2021-12-02

    Introduced the Project functionality to monitor the accessibility of multiple pages of a web site.
    Within a project, multiple audits can be created to evaluate the web pages. Audits can be executed just once or scheduled at fixed interval.
    Such new functionalities allow users to compare and improve the accessibility of a web site over the time.The difference between the Multipage Evaluation and the Project concerns the results of the evaluation: in the first case, each Multipage evaluation is atomic and not related to other Multipage Evaluations even if the the base url is the same; while the Project functionality introduces the concept of Audit (there can be multiple audits for the same project) allowing users to do multiple evaluations of the same web pages belonging to the project and then to compare the evaluation results in order to monitor the evolution of the accessibility over the time.

MAUVE++ Info

What is MAUVE++ and its functionality?

M.A.U.V.E. (Multiguideline Accessibility and Usability Validation Environment) is a system to evaluate accessibility of Web sites by checking their HTML and CSS code through guidelines, which are to be specified through an XML-compliant specification language called L.W.G.D (Language for Web Guideline Definition) that maintains the guidelines separated from the underlying logic. MAUVE++ aims to reduce the cost of validation, increase consistency in the identification of the problematic parts, and extend the set of features that can be assessed. It is not able to identify all the possible accessibility problems since in some cases human intervention is necessary for this purpose.Its main features are: .

  • Validation separated from guidelines’ definition.
  • Guidelines formalized through an XML language, capable of expressing all the past, present and (virtually) future accessibility guidelines.
  • Browser’s plugin for the validation of dynamically created/modified Web pages. Download MAUVE extension for Chrome Browser.
  • Possibility of analyzing the versions of a web-site specific for certain types of device (e.g. mobile versions, desktop version, etc.).
  • Potentially expandable as a system for continuous monitoring of accessibility of web sites’ sets.

MAUVE++ is easy to use. At https://mauve.isti.cnr.it, you can indicate the way what to evaluate (single page or multi page validation) and enter the corresponding web address.


How accessibility metrics are measured in MAUVE++.

In order to indicate the level of accessibility detected MAUVE++ provides two metrics.

  • Accessibility Percentage which indicates how much the website is accessible in terms of the number of checkpoint types successfully evaluated over the total number of evaluated checkpoints for which the tool has been able to make a decision (fail or pass) about the validation.
  • Evaluation Completeness, indicating the percentage of evaluated checkpoints type for which the tool has been able to make a decision (fail or pass) about the validation.

Guidelines and standards that MAUVE++ use.

MAUVE++(Multiguideline Accessibility and Usability Validation Environment) is a system to evaluate accessibility of websites by checking their HTML and CSS code through guidelines, it provides validation results for different types of stakeholders, and supports validation of W3C guidelines.


Download the full list of techniques supported by MAUVE++

Download from GitHub the supported guidelines definition in the XML language

At the moment MAUVE++ is able to validate the accessibility of web pages in relation to the following guidelines:

How does MAUVE++ handles the reports?

Depends on the validation type (single or multi page, MAUVE++ will report the results in 3 different way:

  • a report in EARL
  • a PDF report with the results of the evaluation of the entire website, that the registered user receives by email
  • a web interface report of single web page validation, which has a separate view according to whether the user is a web developer or an end user without programming knowledge

Static Web Page validation VS Server Side Rendering Validation

In the traditional Static Web Page validation, the validation tool downloads the HTML and the CSS ofthe page, then it parses and validates the corresponding DOM

Using the Server Side Rendering Validation, the validation tool does not parse the static web page code, but it exploits the Puppeteer library to load the HTML (and CSS) code in a headless version of the Chrome browser. In this way, it simulates the loading phase as if the page were open in the user's browser and then performs the validation on the DOM of the resulting page obtained by also performing the scripts included in it.
This can be useful in case of Single Page Applications, but more in generally it can provide a more complete validation.
Of course, since the page will be loaded in a headless version of Chrome and then validated, the validation completion time will be longer than standard Static HTML validation.

Problems or feedback??

MAUVE++ is not perfect. If you are having difficulties using MAUVE++ or have feedback or recommendations, please send us feedback.