RE: Proposal for 1.3, "Ensure that information, functionality, and structure are separable from presentation"

Part of the exchange between Gregg and Joe:

<blockquote>
Gregg wrote:
> [...]Is it structure we are trying to 
> preserve or is it information we are trying to not lose?  That is the 
> discussion point.

JOE:
It's a discussion point for people who don't accept that we're already 
making Web *content* accessibility guidelines, admittedly, yes.
</blockquote>

There are two different issues here, and  reminding us that we're
writing guidelines for accessible content doesn't make the points moot.

It seems to me we're trying to ensure that neither "information" nor
structure is "lost" through being inappropriately bound up in
presentation.  By "information" in this context I mean the message an
author wants to send to readers/users; the data, analysis, etc., etc.;
the knowledge s/he hopes to impart.  By "structure" I mean the way
"informaiton" is organized, as expressed in whatever code the author's
chosen technology requires. And let's add for the sake of argument that
"content" includes both information and structure in the senses cited
above.

As I said in an earlier post, the problem isn't that someone might be
silly enough to publish an empty document.  The problem is that someone
might publish content that some users would perceive while other users
would find the "same" content completely *imperceptible* solely by
reason of their disability.

I believe that the intent of GL 1.3 is to guard against that
possibility, and the success criteria should define what must be true of
content in order to accomplish the goal.

John


"Good design is accessible design." 
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Gregg Vanderheiden
Sent: Sunday, May 01, 2005 9:00 am
To: 'Joe Clark'; 'WAI-GL'
Subject: RE: Proposal for 1.3, "Ensure that information, functionality,
and structure are separable from presentation"



Hi Joe,

Thanks for all your work on this.
My replies/answers are marked GV without *'s and >'s in front of them

 


> This means use (X)HTML, basically. It could also mean tagged PDF. I 
> have a technique in mind for plain-text documents that we could talk 
> about later.
>
> ** GV:  If there is to be a limitation - it must be reflected in SCs 
> or
JPEG will be covered.

JOE: 
No, that represents a misunderstanding of the data formats in use on the

Web.


GV:  I don't understand your comment here.  I was talking about the
standard rather than data formats.  The SC should reflect the guideline.
If all the SC are intended to inherit a limiting provision - it must be
stated in each
SC so they can stand independently for conformance testing.   When you
clipped the above text out of the original email you cut off the first
part so it is hard to see what I mean without going back to the original
post. But if you do, you will see that the intended limitation isn't
included in
the wording of each SC - and I think you meant for it to apply.   So I
was
just saying that if you want the "if such and such is true" to apply to
each SC, then you need to put it in the SCs - you can't rely on its
being in the
guideline to carry it over to the SCs.   That's all. 



> So now that you're using (X)HTML or tagged PDF, you have to use the 
> correct element for whatever you're encoding (*within reason*; there 
> will always be exceptional cases where authors must approximate). This

> handily takes care of the obsession with emphasis found in previous 
> versions.
>
>
>> ** GV:  To the extent possible needs to be made objective.

JOE:
No, it does not. The semantics of HTML coding are expressed, sometimes 
quite imperfectly, in HTML specs. Competent authors agree most of the 
time. The rest of the time, it is up to the author to approximate.

This is not a machine-testable outcome and never can be. If you want to 
use the 80%-inter-rating rule, fine.


GV:  By being more objective - I was referring to the 80% IRR.  I didn't
mention anything about machine testing - and we don't require it
anywhere in
the guidelines - though it is nice when it is possible.   "to the extent
possible" is not generally considered objective enough to meet the 80%
rule. That is all. 






> ** GV: this looks like part of the 4.2 discussion.  What if there is 
> no accessibility features available.  Can I use the technology and 
> just not have it accessible?

Which exact technologies are you talking about?

GV: See above.  I am talking about new technologies (like PDF, flash,
etc.)
that continually come into being.     





> 	Level 2 success criterion
>
> 	Only markup languages and technologies that enable
> 	separation of structure, presentation, and behaviour are
> 	used.
[...]

> ** GV:   Ah here it is.   Hmmmm. I don't think we should do this.  But
we
> should require alternate presentation if it is not possible with the 
> technology talked about.

I don't understand the objection.

GV: Ok.  Couple of example problems with it would be  
1) the proposed SC outlaws text.  (we may want to do this but I'm not
sure.)

2) an author should be able to use whatever an author wants, including
technologies that are accessibility opaque (completely inaccessible), as
long as they also provide the information and functionality in an
accessible fashion as well.  Again - not as good - but possible.

Maybe this could be a level 3 SC and be ok.  But I'm afraid it might
outlaw
some newer technologies at level 2.   Would be a good topic for
discussion. 
 


Gregg wrote:
> Plain text though is a question. Is it structure we are trying to 
> preserve or is it information we are trying to not lose?  That is the 
> discussion point.

JOE:
It's a discussion point for people who don't accept that we're already 
making Web *content* accessibility guidelines, admittedly, yes.

If you run a Web site with nice valid code and somebody hands you a 25K 
plain-text file you want to post, you shouldn't have to spend an hour of

your life you'll never get back turning that into HTML. You should just
be 
able to post it.

If your photo-gallery page has alt texts on the thumbnails that, when 
clicked, show you nothing but the larger image with no surrounding HTML,

you should not have to custom-write some kind of content-management
system 
to enclose those larger images in an alt text you will already have had
a 
chance to read.


GV: I don't understand  your comments here Joe.  I was agreeing with
your observation on plain text; - and that although plain text seemed to
violate the rules it also looks like plain text should be acceptable (at
least at
level 1 or 2).   So I was questioning some of the precepts that would
make
plain text fail.  Do we want plain text to fail at level 2 - and require
all plain text docs to be converted?  I didn't think so - and you don't
either I
gather.  But the criterion would seem to imply this.   

Regarding your comments about photos - I didn't mention anything about
photos.  And I am not sure what photos have to do with plain text docs
failing.  (though I would agree with your analysis of the problem you
posed)




And from the beginning of the post.

> **GV:   Good points.   Does this give a blank check though to
technologies
> that could but don't bother to allow this

JOE:
Like what? SVG?
I think the objection is not significant.


GV:  Again, the text I was commenting on was cut off so it is hard to
follow this but the part I was commenting on dealt with adding the
phrase " any access features present" to the provision.  This would mean
that authors would only have to worry about the provision if the source
technology had accessibility features in it. If it did not - then the
author could ignore
the provision because they would automatically conform.   

We found that when writing guidelines - especially technology
independent
ones, we need to choose wording carefully.    To date, technologies like
PDF
have worked to build in access because they had to in order to pass
accessibility provisions.  If we rewrite them to say that authors work
would pass as 'accessible' at some level if they use "any access
features present"
-- then it is in fact easier to conform to this guideline if you choose
a
technology that doesn't have provisions for this than if you do.   

If the problem is important enough for us to include a requirement that
it be solved - then I was saying that using a technology that doesn't
address the problem - shouldn't result in a decision that the need was
met.  

This approach would also result in much lower incentive to technology
developers to build access provisions into the technologies.   If it is
in
fact easier for authors to pass a particular SC if the technology they
choose doesn't have provisions - then why would they ask for that to be
added to the technology - (since it would just mean that they had to do
more work to conform). 

That's all I was saying.   A side thought is that if we feel that some
of
our provisions should be drop-able if the technology doesn't support
them - then maybe we should be dropping them for everyone - or putting
them at level 3. 


Again - thanks for all your work on this Joe.   Lots of good ideas in
your
compilation.   And it raised lots of other things that were not obvious
that
we need to think about and decide as a group. 

Gregg
  


--

Received on Monday, 2 May 2005 13:26:21 UTC