Re: Comments on W3C mobileOK Basic Tests 1.0 January 2007

On 2/13/07, Christophe Strobbe <christophe.strobbe@esat.kuleuven.be> wrote:
>
> Hi,
>
> Below are a few comments and questions about the working draft [1].
>
> * 3.1 AUTO_REFRESH (partial) and REDIRECTION
> The draft states: "This test does not determine whether the user is
> able to opt out of refresh."
> Is the possibility of opting out going to be covered elsewhere?
> Using <meta http-equiv="refresh" content="..." /> fails three
> different success criteria of the Web Content Accessibility
> Guidelines 2.0 (see failure F40 in "Techniques for WCAG 2.0" [2]).
> This is because screen readers will start reading from the top of the
> page again when the page refreshes, thereby taking away control from
> the user over his interaction with a page.
> Server-side redirects [3] are preferable, but WCAG 2.0 currently also
> allows client-side redirects if they have no timeout: see techniques
> G110 (Using an instant client-side redirect [4]) and H76 (Using meta
> refresh to create an instant client-side redirect [5]).

mobileOK Basic Tests are intended to be machine-testable. The test
here corresponding to the AUTO_REFRESH best practice only partially
covers that best practice since one can't write a test that reliably
detects whether there is, for example, a link on the page that would
stop the redirects.

While the Mobile Web Best Practices and WCAG have different goals,
redirection is discouraged by both. The test stated in mobileOK Basic
Tests only warns on auto-refresh since the best practice is to not use
auto-refresh unless you provide a way to stop it, and, it's not
possible to determine that by a program.

The corresponding test (human-testable, potentially) in mobileOK (not
mobileOK Basic) should address this of course.

> Note that the if statements for the meta element and the HTTP refresh
> header are different: one refers to "the current resources's URI",
> while the second refers to "the current page". Shouldn't the same
> wording be used in both cases?

I think so, good catch.

>
> * 3.4 CONTENT_FORMAT_SUPPORT
> People are aware of validators for HTML, XHTML and CSS, but how do
> you check if an image is valid according to GIF89A or JPEG? Do image
> editors check this or do they just check whether the images are "good
> enough" for the editor? Could you provide pointers to tools that are
> reliable "validators" for GIF89A and JPEG?

Valid here just means that the bytes are the encoding of some image in
that format, according to its official specification. Java, for
example, provides the "imageio" library for parsing images and I'd
imagine will throw an exception if the bytes don't seem to encode an
imagine according to the given format.

While GIF89A is pretty specific, I have a feeling we'll need to
tighten up exactly which flavor of JPEG we're talking about here.


> * 3.9 IMAGES_RESIZING and IMAGES_SPECIFY_SIZE
> This prohibits the definition of image size in style sheets [6]. Is
> that intentional or an oversight?

The intent is to make sure that the client browser knows how large the
image will be so as to avoid re-flowing the page. I *think* the
reasoning is that it's desirable to specify this in the height and
width attributes instead of CSS styles so that this information is
available without CSS styles. Separately, other best practices
encourage authors to make their pages as usable as possible even
without styles.

I can bring this up at the next call to see if anyone else has thoughts on this.

> * 3.14 NON-TEXT_ALTERNATIVES (partial)
> The draft states: "This test does not determine whether the
> alternative text is meaningful." Why not? Doesn't a meaningless text
> alternative defeat the purpose of the alt attribute?
> Note that the current working draft of WCAG 2.0 requires: "text
> alternatives serve the same purpose and present the same information
> as the non-text content. If text alternatives cannot serve the same
> purpose, then text alternatives at least identify the purpose of the
> non-text content" (this is just part of success criterion 1.1.1 [7]).

You're right, and while the machine-testable mobileOK Basic Tests
can't check this, this should certainly be covered in mobileOK Tests.

> * 3.24 TABLES_LAYOUT (partial)
> The draft states: "This test does not catch all cases where tables
> are used for layout purposes." I agree. "Techniques for WCAG 2.0"
> also has a test for layout tables [8]:
> "Check for layout tables: determine whether the content has a
> relationship with other content in both its column and its row. If
> 'no,' the table is a layout table. If 'yes,' the table is a data table."
> Would that be a better fit? Obviously, the test from WCAG 2.0 cannot
> be automated.

Same comment, yes. This should certainly be part of the mobileOK
tests. The mobileOK Basic tests attempt to automatically catch some
cases without generating false positives.

Thanks!
Sean

Received on Tuesday, 13 February 2007 21:07:09 UTC