Re: Author incentives for accessibility

At 06:51 -0400 UTC, on 2007-05-18, Matthew Raymond wrote:

[...]

> [...] I think that the only successful accessibility-related
> technologies will be the ones that require trivial-to-no work on the
> part of web developers.

[assuming that with "web developers" you mean people who publish content on
the web -- I prefer to say "web publishers"]

I agree, although I'd replace "only" with "most".

The easier it is for authors to pubilsh documents in an accessible way, the
more likely the Web's accessibility will improve.

I think the biggest problem today is that web publishers [1] just don't
understand "accessibility" and [2] find much of the available techniques too
difficult. In that sense I think there is value in the argument that whatever
special accessibility techniques HTML 5 defines should be as easy to author
as possible. However, not at the cost of accessibility. If some things cannot
be made "easy", they'll just have to be "difficult" (until in HTML 6. 7, or 8
we think of an easier to use technique). At least the web publishers and UA
authors who do understand will be able to use it, and thus at least some end
users will benefit.

Additionally it's worth to consider how easy it would be for an authoring
tool to generate such markup. It may be that some technique is difficult to
author 'manually', but can be made easy through authoring tools. (A few
examples could be
<http://webrepair.org/02strategy/02certification/01requirements.php#req21>
and
<http://webrepair.org/02strategy/02certification/01requirements.php#req26>.)

I'm all for keeping HTML a language that can be 'hand authored'. But there is
a clear trend that more and more content is being published using HTML
generating tools. So if some accessibility technology can be authored
relatively easily through authoring tools, it is probably well worth speccing
it even when we expect that for most 'manual authoring' it wil be too
difficult.

[...]

> the two examples given boiled down to the following:
>
> 1) The 10% of the population that needs accessibility features justify
> whatever new markup is necessary.
>
> 2) The law requires a minimal level of accessibility.
>
>    Example #1 isn't necessarily true for two reasons. First, assistive
> technologies will evolve to support whatever the markup of the Internet
> is.

But that can only solve today's accessibility problems up to a point. There
will always be a burden on the web publisher to bother to provide descriptive
markup. No UA will be able to figure out on its own when a paragraph
preceding a table should be considered a summary for that table. The web
publisher needs to bother to provide that info.

Talking about author incentives: my impression is that many of the techniques
that today are considered to be aimed at specific handicaps provide
insuficient incentive exactly because of that. If your average desktop UA
would do useful things with such markup, the incentive would be *much*
stronger. Examples are (lack of) LINK support in UAs, UAs not indicating the
existence of title attributes, UAs not presenting tbody scrollable, etc.

Consider the previous summary example: if UAs would provide users with an
easy way say "print this particular table", web publishers will more likely
understand that that preceding paragraph should be attached to the table, and
will hopefully mark it up as the table's summary.

If UAs would print the title attributes of abbreviations (perhaps as
footnotes), more web publishers will realise that it's worth the trouble to
properly markup abbreviations.

If UAs would reprint thead on every page, when a table doesn't fit a single
page, more web publishers will realise that it's worth the trouble of
bothering to provide such markup.

[...]

> Second, since that 10% of the market requires greater resources to
> tap, there economic pressure not to support these individuals. We have
> to make sure HTML5 markup doesn't create a law of diminishing returns
> relative do individuals with disabilities.

Quoting <http://webrepair.org/01why/#accessibility>: "accessibility applies
to any type of access, not just to people with disabilities. When access to
some content is made dependant upon some technique that cannot be relied upon
to be available (javascript, CSS, Flash, PDF, any specific Web browser,
etc.), accessibility is degraded. When DIV soup replaces semantic mark-up,
accessibility is degraded. When things like font-size are not left up to the
user, accessibility is degraded. When only access through large screen/high
bandwidth desktop computers is anticipated, accessibility is degraded."

Accessibility applies to all of us.

Practical example, relating to the headers attribute debate: when a table
doesn't fit the viewport, no UA that I know of ensure the table header cells
are always in view. This degrades accessibility to everyone, because it means
you need to either remember, or constantly scroll to look up what data a cell
represents.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Friday, 18 May 2007 17:06:25 UTC