ESOK-hanke 2006-2011

W3C mobileOK Checker

Address: Go to
Result:
This page is not mobile-friendly!

The score equals 100 minus the sum of the costs of failures (see the help page). The score of this page is negative, hence the "not mobile-friendly" message! Here is the repartition of costs per failure severity:

Severity Number Total cost
critical 2 46pt
severe 5 50pt
medium 1 5pt
low 5 22pt
Page Size:
49KB
document: 2KB - stylesheets: 46KB - images: <1KB
Network:
3 requests
document: 1 - stylesheets: 1 - images: 1

Help on the checker is available.

Where to start...

2 critical error(s) detected!
>These errors typically prevent the rendering of at least part of the page on mobile devices. Critical errors should be addressed first. Here is the list: <p>

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

Detailed report

  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.

  2. Structure of the page

    Markup validity does not ensure that tags are used appropriately. For instance, given the lack of support for nested tables in mobile browsers and the small screen sizes, using tables for layout will not work on mobile devices. The same goes with the use of applets, frames, pop-ups, and so on. The size of the page is also a very important aspect to keep in mind when designing mobile-friendly pages.

    1. Layout

      Checks that tables are not used for layout and that graphics are not used for spacing.

      • A table with only one row is either the sign that the table is used:
        • to represent a list of items horizontally
        • to control the relative position of various sections of the page
        Both uses imply a layout based on tables. While most mobile devices support basic tables, they are rendered quite differently by different mobile browsers, and cannot be reliably used for layout. The table element should only be used - with care - to represent tabular data.
        Use CSS techniques to control the layout of the page. For instance, if you were trying to render a list of items horizontally, consider:
        >
        • <ul> <li>Item 1<li> <li>Item 2</li> </ul> in the markup of the page
        • ul li { display: inline; } in the CSS style sheet to force the items of the list to be rendered on the same line
        Triggered 2 times by the resource under test:
        … <table cellpadding="0" cellspacing="0" width="100%"><tr><td class="sovellusnimi" colspan="3">SoleTM 3.4.0 - Sole Time Management, Työajan hallinta, ©2003-2009 <a href="http://www.solenovo.fi" target="new">Solenovo Oy</a></td></tr></table>
        … <table cellpadding="0" cellspacing="0" width="100%"><tr><td class="sovellusnimi" colspan="3">SoleTM 3.4.0 - Sole Time Management, Työajan hallinta, ©2003-2009 <a href="http://www.solenovo.fi" target="new">Solenovo Oy</a></td></tr></table>
      • A table with only one column is either the sign that the table is used:
        • to represent a list of items
        • to control the relative position of various sections of the page
        Both uses imply a layout based on tables. While most mobile devices support basic tables, they are rendered quite differently by different mobile browsers, and cannot be reliably used for layout. The table element should only be used - with care - to represent tabular data.
        Use CSS techniques to control the layout of the page. See a tutorial on table-less layout.
        Triggered 2 times by the resource under test:
        … <table cellpadding="0" cellspacing="0" width="100%"><tr><td class="sovellusnimi" colspan="3">SoleTM 3.4.0 - Sole Time Management, Työajan hallinta, ©2003-2009 <a href="http://www.solenovo.fi" target="new">Solenovo Oy</a></td></tr></table>
        … <table cellpadding="0" cellspacing="0" width="100%"><tr><td class="sovellusnimi" colspan="3">SoleTM 3.4.0 - Sole Time Management, Työajan hallinta, ©2003-2009 <a href="http://www.solenovo.fi" target="new">Solenovo Oy</a></td></tr></table>
      • While most mobile devices support basic tables, nested tables are hardly supported. The layout of a page that contains nested tables is unpredictable on mobile devices and at best unlikely to be the desired layout. The table element should only be used - with care - to represent tabular data.
        Use CSS techniques to control the layout of the page. See a tutorial on table-less layout.
        Triggered 2 times by the resource under test:
        … <table cellpadding="0" cellspacing="0" width="100%"><tr><td class="sovellusnimi" colspan="3">SoleTM 3.4.0 - Sole Time Management, Työajan hallinta, ©2003-2009 <a href="http://www.solenovo.fi" target="new"><!-- ...skipped by mobileOK checker... ---></a></td></tr></table>
        … <table border="0" cellpadding="2" cellspacing="2" class="inner_table_login" width="100%"><tr><th class="dataheader_login" width="20%">Käyttäjätunnus</th><td class="datatable_login" width="80%"><input name="user" size="20" type="text" value=""/></td></tr><tr><th class="dataheader_login">Salasana</th><td class="datatable_login"><input maxlength="41" name="password" size="20" type="password" value=""/></td></tr><tr><td class="buttons_login" valign="middle"> </td><td class="buttons_login" valign="middle"><input src="/tyoaikatest/all/gifs/transit.gif" type="image"/><input class="talletapainike_tekstina" type="submit" value="Sisään"/></td></tr></table>
      • Most mobile devices support basic tables. Use tables with care. In particular, if the width of the table is likely to be larger than the width of the mobile device's screen, the result may not be usable for users: rows may be wrapped on multiple lines with no clear way to distinguish between rows and continuation of rows, or the browser may zoom out so that users see the whole table, resulting in words written in too tiny characters to be read.
        >Using tables to control the layout of the page rather than to display tabular data is a bad practice<em> in all cases (mobile or not). Mobile browsers in particular are unlikely to render them as they would be on a big screen.
        Consider converting tables to a linear layout, e.g. using definition lists (dl, dt and dd elements). Instead of a table-based layout, use CSS techniques instead. See a tutorial on table-less layout.
        Triggered by the resource under test:
        … <table align="center" cellspacing="10" class="frametable_login"><tr><td class="frameheader" colspan="2"><!-- ...skipped by mobileOK checker... ---></td></tr><tr><td class="framedata_login"><!-- ...skipped by mobileOK checker... ---></td></tr></table>
        Related best practice:
        >[/www.w3.org/TR/mobile-bp/#TABLES_ALTERNATIVES">/www.w3.org/TR/mobile-bp/#TABLES_ALTERNATIVES">TABLES_ALTERNATIVES] Where possible, use an alternative to tabular presentation.
    2. Page weight

      The size of the page includes the page itself, the external style sheet(s), and the embedded images and objects. mobileOK requires the total size of the page to be under 20 KB, and the markup itself to be under 10 KB to ensure that the page can be retrieved and rendered by a mobile device in a reasonable amount of time.

    3. Scripting

      Scripts can be used as long as scripting support is not required, since many mobile browsers have limited or no support for Javascripts.

      • Scripting can be used, but shouldn't be relied upon, since many mobile devices do not support or hardly support scripting. The page should still be usable when scripting is not enabled.
        Use scripting to enhance your page, but degrade gracefully when scripting is not supported.
        Triggered 5 times by the resource under test:
        … <script language="javascript" src="/tyoaikatest/all/js/soletm.js?version=3.4.0" type="text/javascript"/>
        … <script language="javascript" src="/tyoaikatest/all/js/soletm_viikkotuntiajax.js?version=3.4.0" type="text/javascript"/>
        … <script language="javascript" src="/tyoaikatest/all/js/ajax.js?version=3.4.0" type="text/javascript"/>
        … <script language="javascript" src="/tyoaikatest/all/js/dragndrop.js?version=3.4.0" type="text/javascript"/>
        … <script language="javascript" src="/tyoaikatest/all/js/ajax_info.js?version=3.4.0" type="text/javascript"/>
    4. Inclusions

      Frames, pop-ups and applets are not at all mobile friendly. Usage of the object tag with its fallback mechanism needs particular care to avoid unnecessary downloads.

    5. Image maps

      Checks that image maps are not used.

  3. Style sheets

    The most efficient way to control the layout of a page is to use CSS style sheets. To use them well in a mobile browser, it is important to ensure that the CSS style sheets referenced by a page and the CSS styles directly defined in the page are valid, and e.g. make a good use of the @media rules.

  4. Images/Objects

    Images and/or image objects must be delivered in an appropriate format and dimensions so that they can be retrieved and rendered by most mobile browsers. mobileOK requires that all images and rendered objects be either GIF or JPEG images.

  5. 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.

? Top

  1. User input

    Keyboard and other input methods on mobile devices can be tedious to use. Inputs should be minimized. Default values should be provivded to guide the user whenever possible.

  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