W3C home > Mailing lists > Public > public-html@w3.org > July 2009

Re: Nothing is really hidden

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 1 Jul 2009 14:45:30 -0700
Message-ID: <63df84f0907011445m6b4052cek336443dfd3b426fd@mail.gmail.com>
To: Shelley Powers <shelley.just@gmail.com>
Cc: HTMLWG WG <public-html@w3.org>
On Wed, Jul 1, 2009 at 1:47 PM, Shelley Powers<shelley.just@gmail.com> wrote:
>>> True, there may be some tools that automatically fill in the summary
>>> attribute with incorrect values, and the web page author is not
>>> allowed to edit the field via the tool. But I would say that was a
>>> problem with the tool, not necessarily @summary.
>>
>> Why only tools that automatically fill in the summary? What if the
>> ability to fill it out is hidden away in some 'table properties'
>> dialog box? Or what if the summary was filled out back when the site
>> was created using a plain texteditor and has been left since then.
>>
>>> As far as I know, the
>>> value isn't hidden from either the author or QA, regardless. At a
>>> minimum, they could check the value by looking at the page source.
>>
>> I don't think your average QA person is going to look at the page
>> source to ensure that it is correct.
>
> A bit off-topic, but a good discussion point. My response is, it's
> hard to say. I'm assuming that if the company or organization (or
> individual) is interested in ensuring his, her, or their site is
> accessible, they would do whatever it takes to ensure the site is
> accessible. I would find it more likely they would use AT software,
> like JAWs. But I imagine there's other tools they could use, too.

I think the problem is that all too few organizations give AT users
all too low priority.

I think we've tried to attack the problem of getting the web
accessible from two directions:

1. Make it possible for sites that actively try to get their AT users
friendly, to do so.
2. Make sites that weren't developed with AT users in mind as
accessible as possible for AT users.

@summary and ARIA falls into category 1 since it allows sites with
complex markup to add additional markup specifically to make it
consumable by AT users.

<input type=date> falls into category 2 since AT tools can communicate
to the user that a date is expected and help the user enter a date.
This works even if the site makes no effort to cater to AT users.

> To return to my point, and sorry if I seem to be belaboring it: I
> think that the use of 'hidden' for certain elements and attributes
> could negatively impact on how they are perceived, or valued. I think
> its important to look at these values (and that includes semantic
> markup, not just accessibility markup) as targeted to a different
> subset of users, rather than just define them, generally, as 'hidden'.

What I read into 'hidden' is that it's less likely that people will
use it at all, and even less likely that they'll use it correctly.
Hence it will probably help users that rely on it less.

Apart from if @summary is harmful or not (I happen to not think it's
harmful per se), I strongly believe that it's used much less than it
should, and thus doesn't help AT users to the extent that they do need
help.

/ Jonas
Received on Wednesday, 1 July 2009 21:46:35 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:47 UTC