Go to
Result:
88/100
 

The score equals 100 minus the sum of the costs of failures (see the help page). Here is the repartition of costs per failure severity:

Severity Number Total cost
severe 1 10pt
low 1 2pt
Page Size:
6.8KB
document: 4.5KB - images: 2.3KB
Size Type URI
4.5KB document Resource under test
2.3KB image http://m.milannews.it/template/milannews.it/img/logod_mobile.gif
Network:
2 requests
document: 1 - images: 1
Type URI
document Resource under test
image http://m.milannews.it/template/milannews.it/img/logod_mobile.gif

Check out W3C's training courses for mobile!

Help on the checker is available.

Where to start...

1 severe error(s) detected!
While severe errors may not prevent the rendering of the page on mobile devices, they negatively impact the user experience. They should be addressed first. Here is the error:

Follow the links above for a detailed description of each message and suggestions to fix the underlying problem.

Detailed report

  1. Character Encoding

    Checks in this category ensure that the content is properly encoded, and that the encoding being used is properly advertised in the HTTP headers. See Introducing Character Sets and Encodings for an overview of this topic. mobileOK requires that the content be made available encoded in UTF-8.

    • Error [severe] The document is not valid UTF-8
      The content of the page is not properly encoded in UTF-8, and thus is likely to trigger parsing or rendering errors in mobile browser.
      If the page under test uses an encoding other than UTF-8, this failure message merely confirms that the page is not encoded in UTF-8. The mobileOK Checker specifically requested a UTF-8 representation of the page through an HTTP Accept-Charset header to check that the resource is available in UTF-8 encoding. Given the number of character encodings used across the world, sending UTF-8 encoded content to browsers that request it increases significantly the chances of properly displaying a page.
      Triggered by the resource under test.
      Related best practice:
      [CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character encoding that is known to be supported by the device.
    • Error [low] The HTTP Content-Type header specifies a character encoding other than UTF-8
      The page under test uses a character encoding other than UTF-8. Given the number of character encodings used across the world, sending UTF-8 encoded content to browsers that request it increases significantly the chances of properly displaying a page.
      See how to set the charset information in Apache and learn more about Unicode and UTF-8.
      Triggered by http://m.milannews.it/.
      Related best practice:
      [CHARACTER_ENCODING_SUPPORT] Ensure that content is encoded using a character encoding that is known to be supported by the device.

↑ Top

  1. Markup

    The quality of the markup sent to mobile browsers will impact the reliability and smoothness of the rendering of the page. Markup validity is the first step to delivering content that can be parsed and rendered reliably by browsers. The recommended markup format for mobile content is XHTML Basic 1.1. But beyond validity, various tags and attributes have a specific impact in the mobile world. For instance, CSS style sheets should be used to control the layout of the page instead of presentational tags (e.g. center, big, or font) and images sizes should be defined in the markup to avoid reflows.

    • Warning The documents uses one of b, big, i, small, sub, sup or tt elements
      Presentation effects should be defined separately from the content, in a CSS style sheet that can be re-used and cached across pages.
      Use CSS style sheets to control the layout of the page.
      Triggered by the resource under test:
      … <b>ALTRE NOTIZIE</b>
      Related best practice:
      [STYLE_SHEETS_USE] Use style sheets to control layout and presentation, unless the device is known not to support them.
  2. At the HTTP level

    The source of the messages in this category is to be found in the HTTP headers that were sent along with the page. They are most likely due to the Web server configuration for static files, or the way the server-side scripts are written for dynamic content. Making sure that HTTP headers are correctly defined is essential in a mobile context with a usually low bandwidth and high latency.

↑ Top