W3C home > Mailing lists > Public > public-wcag2ict-tf@w3.org > September 2012

Re: examples of sets of documents

From: Peter Korn <peter.korn@oracle.com>
Date: Tue, 11 Sep 2012 15:21:48 -0700
Message-ID: <504FB97C.2000506@oracle.com>
To: Gregg Vanderheiden <ez1testing@gmail.com>
CC: "Hoffman, Allen" <Allen.Hoffman@HQ.DHS.GOV>, Alex Li <alli@microsoft.com>, Loďc Martínez Normand <loic@fi.upm.es>, Gregg Vanderheiden <gv@trace.wisc.edu>, "public-wcag2ict-tf@w3.org" <public-wcag2ict-tf@w3.org>
Gregg,

Follow up comment: While the two examples you found were quite helpful 
(for me at least) in tackling this SC, I wouldn't include those specific 
examples in the actual WCAG2ICT text.  I think we should either create 
our own examples that would then be hosted on the W3C website and that 
DO have good filenames that are sufficiently descriptive; or simply not 
have any examples in the actual WCAG2ICT text.


Peter

On 9/11/2012 3:16 PM, Peter Korn wrote:
> Gregg,
>
> Looking at proposal #10, I think we are almost there.  I would like to 
> see us use language parallel to what is in SC 2.4.2 for software, 
> namely the sentence fragment from the sentence (emphasis added): 
> "However, since there is almost always a single user interface 
> component associated with top-most explicit groupings of user 
> interface components (things like "windows", "dialog boxes", "frames", 
> and "screens"), and since 4.1.2 requires that every user interface 
> component has a programmatically determined name, /*conforming to 
> 4.1.2 would thereby mean that this success criterion was met if the 
> name for the user interface component associated with top-most 
> explicit groupings of user interface components described its topic or 
> purpose*/."
>
> Applying this to your proposal #10, the final note #6 would then 
> become (/*additions emphasized*/):
>
>     Authors can assume that an infrastructure exists that allows users
>     to locate documents in the set; for example, by selecting links
>     within a member document, browsing through the files that make up
>     the set, or by searching the documents' contents or the names of
>     the member documents, since document names and the ability for
>     machine access to the text are required by other success criteria.
>     *Therefore conforming to SC 2.4.2 would thereby mean that this
>     success criterion was met.*
>
>
>
> Regards,
>
> Peter
>
> On 9/11/2012 3:08 PM, Gregg Vanderheiden wrote:
>> Well it does apply.  And if people did NOT name the files in a clear 
>> way or have links in the docs (one or the other) then it  would not 
>> meet this SC.  So it applies and is important.   It just is not a 
>> problem if you take the fairly simple (but not always done) step of 
>> naming the file so that you can find the parts.
>>
>> As you point out, we are not charged with or authorized to tell the 
>> Access Board or M376 or anyone else what rules should or should not 
>> be applied.  We were only charged with explaining how it would be 
>> applied.
>>
>> Since naming the file something logical is easy and also meets both 
>> this and the TITLE success criterion I'm not sure why we are spending 
>> all this time on this.
>>
>> There is something that is important to be done. Doing it is easy and 
>> meets at least two success criteria.
>>
>> Peter, all,  there is now a  proposal that includes the info from the 
>> discussion today and I think makes it clear.  Here I wish we could 
>> just say "one way of meeting this is"  but that gets us into 
>> techniques land.  So I tried to do everything I could.  Give it a 
>> read and see what you think.
>>
>> Gregg
>>
>>
>>
>> On Sep 11, 2012, at 4:53 PM, "Hoffman, Allen" 
>> <Allen.Hoffman@HQ.DHS.GOV <mailto:Allen.Hoffman@HQ.DHS.GOV>> wrote:
>>
>>> Mostly we are working this because we were not given the option of 
>>> recognizing that sometimes an SC doesn't apply in a particular 
>>> environment true or not.
>>> *From:*Alex Li [mailto:alli@microsoft.com <http://microsoft.com>]
>>> *Sent:*Tuesday, September 11, 2012 5:49 PM
>>> *To:*Peter Korn; Hoffman, Allen
>>> *Cc:*Gregg Vanderheiden; Loďc Martínez Normand; Gregg Vanderheiden; 
>>> public-wcag2ict-tf@w3.org <mailto:public-wcag2ict-tf@w3.org>
>>> *Subject:*RE: examples of sets of documents
>>> Despite the fact that we still don’t have adequate clarity on how 
>>> this SC works in the context of documents, we all seem to be saying 
>>> that this is trivial.  If so, why are we wasting so much time trying 
>>> to preserve a trivial SC?  Should we put our effort into casting the 
>>> SC out instead of wasting more time trying make it work?  I’m open 
>>> to a note per Peter’s suggestion or deleting the SC in the context 
>>> of documents.
>>> *From:*Peter Korn [mailto:peter.korn@oracle.com]
>>> *Sent:*Tuesday, September 11, 2012 2:36 PM
>>> *To:*Hoffman, Allen
>>> *Cc:*Gregg Vanderheiden; Loďc Martínez Normand; Gregg 
>>> Vanderheiden;public-wcag2ict-tf@w3.org 
>>> <mailto:public-wcag2ict-tf@w3.org>
>>> *Subject:*Re: examples of sets of documents
>>> Allen, gang,
>>>
>>> In addition to the two NOTEs that Gregg has proposed in this thread, 
>>> why not also make this really easy for folks - assuming it is so 
>>> trivial to meet in the desktop GUIs of today - by adding a third 
>>> NOTE that makes that abundantly clear.  Let's not waste developers' 
>>> (and procurers') time & brainpower to walk through the various steps 
>>> in order to conclude that this is trivially / automatically met; 
>>> let's spell that out clearly (perhaps similarly to what we [tried 
>>> to] did with AccessibleName for top-level frame as a way to meet SC 
>>> 2.4.2).
>>>
>>>
>>> Peter
>>>
>>> On 9/11/2012 5:01 AM, Hoffman, Allen wrote:
>>>
>>>     I agree with all Peter’s points here.
>>>     If this just becomes trivial to meet but is not really
>>>     procedurally and/or culturally normative to just say this makes
>>>     little sense to apply in this context, then as long as we
>>>     clearly state these conditions I can live with that.
>>>     *From:*Peter Korn [mailto:peter.korn@oracle.com]
>>>     *Sent:*Tuesday, September 11, 2012 2:16 AM
>>>     *To:*Gregg Vanderheiden
>>>     *Cc:*Loďc Martínez Normand; Gregg
>>>     Vanderheiden;public-wcag2ict-tf@w3.org
>>>     <mailto:public-wcag2ict-tf@w3.org>
>>>     *Subject:*Re: examples of sets of documents
>>>
>>>     Gregg,
>>>
>>>     Comments in-line below:
>>>
>>>     On 9/10/2012 9:51 PM, Gregg Vanderheiden wrote:
>>>
>>>         Peter, Loic,
>>>         You were having trouble seeing how these could meet the SC
>>>         1) these are on the web so the question is would they meet
>>>         WCAG --  And the answer is yes.  Browsing  and searching.
>>>
>>>
>>>     PK: Neither browsing nor searching work JUST FROM THE TWO (pairs
>>>     of) URLs YOU DISTRIBUTED TO US.  They might be on a website with
>>>     either a search function and the ability to browse, but we
>>>     didn't see that.  Therefore, given what we had (e.g. a "web
>>>     site" consisting of only two URLs), I still maintain that they
>>>     as such didn't meet WCAG.
>>>
>>>     2) if they were NOT on the web - the question isn't whether they
>>>     DO or not but whether they easily could or not.
>>>
>>>
>>>     PK: I'm sorry, I misunderstood your reply.
>>>
>>>     2a) another question (ala Alan) is whether they could meet the
>>>     SC  WITHOUT having to open them up and re-edit them.
>>>     The answer to  (2) and (2a) is yes for both.
>>>     Walking this through.....
>>>     Assuming you are distributing these in some fashion besides the web.
>>>
>>>       * If on the web then use WCAG directly.
>>>       * If a person downloads them from the web then -- all bets are
>>>         off.  WCAG doesn’t cover that we we don't either.  It was on
>>>         the web and met WCAG.  If the user choses to pull it into
>>>         another environment -- then the author is not responsible
>>>         any more than if they broke them apart or printed them as
>>>         image documents to their drive or anything else.
>>>
>>>     So - back to assuming you are distributing them in some way
>>>     other than the web.  You are distributing one of these sets on a
>>>     flash drive or dvd or zipped and mailed to someone or  on a file
>>>     servers or in some other non-web fashion.
>>>     Since you are doing so, you would, should, (or at any rate -
>>>     easily can), give them a meaningful file name before you
>>>     distribute them.
>>>     This will allow you to meet SC 2.4.2. Page Title
>>>
>>>
>>>     PK: Note: that shouldn't be the ONLY way to meet SC 2.4.2.
>>>
>>>     It also give you (or rather, you give the user) two simple
>>>     methods which would meet SC 2.4.5.
>>>     1) the user can browse to them in the Finder or Windows Explorer.
>>>     2) the user can use the search function in the Finder or Windows
>>>     Explorer.
>>>     Both techniques are ways the user can use to find the documents.
>>>
>>>
>>>     PK: I still don't follow.  Let us say they have meaningful
>>>     filenames, but neither document refers to the other.  Are you
>>>     saying that, given a "modern" desktop OS that allows searching
>>>     by filename and browsing contents of disks/directories, that SC
>>>     2.4.5 should essentially automatically be met?
>>>
>>>
>>>
>>>     The directory method (#1 above) is a direct parallel with
>>>     technique*/G63 "providing a site map"/*since the directory
>>>     provides a listing of all of the parts of the set.
>>>
>>>
>>>     PK: For this to be used by folks in meeting SC 2.4.5, I believe
>>>     we need a NOTE or other text to direct folks to the non-web
>>>     equivalent of "providing a site map".
>>>
>>>     The search function (#2 above)  is a direct parallel with*/G161
>>>     "Providing a search function to help users find content."/*
>>>
>>>
>>>     PK: Ditto here - this should be made clear in our guidance for
>>>     non-web ICT software if we are to expect folks to use it.
>>>
>>>     If the docs meets the other success criteria then these two
>>>     approaches would work and would do it.
>>>     If the docs do not meet the other success criteria (e.g. they
>>>     don't have meaningful titles when you pass them around to
>>>     others, or are not text ) then they don't conform anyway.
>>>     So you can easily meet this success criterion without editing
>>>     the document at all.
>>>     And if you want to keep the document number (if it has meaning)
>>>     you can do that too.  (e.e.  "document name - 56013d01.pdf"
>>>
>>>
>>>     PK: Finally, making this essentially trivial to meet (meet SC
>>>     2.4.2 & exist on a modern desktop OS and you have automatically
>>>     met SC 2.4.5) I think strips it of nearly all of its meaning and
>>>     value.
>>>
>>>
>>>     Regards,
>>>
>>>     Peter
>>>
>>>     Gregg
>>>     On Sep 10, 2012, at 4:54 PM, Loďc Martínez Normand
>>>     <loic@fi.upm.es <mailto:loic@fi.upm.es>> wrote:
>>>
>>>     Dear all,
>>>     Thank you Gregg for providing these good examples of sets of
>>>     documents, which I agree they are.
>>>     But I'm with Peter about conforming to 2.4.5 (multiple ways). I
>>>     don't think that there two examples meet 2.4.5 either as web
>>>     content or as a set of documents once downloaded in one
>>>     computer. I don't think that the techniques defined for 2.4.5
>>>     are applied in those two examples.
>>>     Best regards,
>>>
>>>     Loďc
>>>
>>>     On Mon, Sep 10, 2012 at 11:16 PM, Peter Korn
>>>     <peter.korn@oracle.com <mailto:peter.korn@oracle.com>> wrote:
>>>
>>>     Hi Gregg,
>>>
>>>     I'm afraid I don't see how these example documents meet 2.4.5
>>>     Multiple Ways - either using Proposal #9
>>>     athttps://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/245-multiple-waysor
>>>     frankly just as web pages using WCAG 2.0.
>>>
>>>     In the Muse Test Suite example, the filenames are
>>>     "MUSE_DTF4.1p_V07.pdf" and "MUSE_DTF4.2p_V05.pdf" (or perhaps
>>>     "6BED1d01.pdf" and "57013d01.pdf" as that is what they get as
>>>     temporary filenames when passed to my copy of Adobe Reader). 
>>>     Neither of these are "Test Suite, Part 1: Test Objectives" or
>>>     "Test Suite, Part 2: Test Methods" - so internal references to
>>>     those filenames don't exist (so I don't see how that would be
>>>     "one of the multiple ways").  This same situation arises with
>>>     the Audacity example - the filesystem filenames don't match the
>>>     document filenames ("Super-Fast Guide to Audio Editing" vs.
>>>     "Audacity_Guide.pdf"   and "Editing Audio with Audacity (Part
>>>     2)" vs. "EditingAudioPart2.pdf").
>>>
>>>     Also, proposal #9 lacks the NOTE at the end of proposal #8, but
>>>     even following that NOTE, since not all documents in both
>>>     examples contain links to the other, the only "way" of the
>>>     necessary at least 2 ways that I find is "searching the
>>>     documents' contents").
>>>
>>>
>>>     So... while I think these are good examples of a "set of
>>>     documents" - at least for purposes of our discussion - I don't
>>>     see them as examples of documents that pass our contemplated
>>>     tests for 2.4.5 (let alone passing WCAG 2.4.5 when viewing them
>>>     as web pages).
>>>
>>>
>>>     Peter
>>>
>>>     On 9/8/2012 2:52 PM, Gregg Vanderheiden wrote:
>>>
>>>         Hi Peter,
>>>         Currently they are web pages.  And the do meet WCAG as web
>>>         pages.
>>>         I can't comment on their meeting WCAG in other contexts since
>>>         a) the other context is not described
>>>         b) the WCAG2ICT hasn’t said how WCAG would be applied to
>>>         those other contexts.
>>>         Given the discussions we have been having in WCAG2ICT though
>>>         -- I would see no problem in the documents meeting what the
>>>         WCAG2ICT has been discussing, and doing so in most any
>>>         context that I can think of  (e.g. saved from an email, on a
>>>         server, in a folder together on a drive, of flash memory
>>>         stick, etc.)  except if you split them up -- but we
>>>         specifically exclude a set that has been broken up from
>>>         being still considered a set -- so I guess they would pass
>>>         that too.
>>>         /Gregg/
>>>         --------------------------------------------------------
>>>
>>>         On Sep 7, 2012, at 12:28 PM, Peter Korn
>>>         <peter.korn@oracle.com <mailto:peter.korn@oracle.com>> wrote:
>>>
>>>         Gregg,
>>>
>>>         Thanks for finding these examples!
>>>
>>>         Looking at the first set (Muse Test Suite), in your opinion
>>>         should these pass or fail the SC?  In your reading of the
>>>         draft SC language, do they pass or fail?  Any why?
>>>
>>>         Same questions for the second set (User Guide to Audio
>>>         editing...)...
>>>
>>>
>>>         Peter
>>>
>>>
>>>         On 9/6/2012 11:29 PM, Gregg Vanderheiden wrote:
>>>         here are two examples
>>>
>>>          1. Muse Test Suite, Part 1 Test Objectives (link
>>>             <http://www.ist-muse.org/Deliverables/TF4/MUSE_DTF4.1p_V07.pdf>)
>>>             & Part 2 Test Methods (link
>>>             <http://www.ist-muse.org/Deliverables/TF4/MUSE_DTF4.2p_V05.pdf>).
>>>
>>>
>>>               * Published together on Jan 6, 2006. Labeled as a set
>>>                 in 1.1 Scope.
>>>
>>>          2. User Guide to Audio editing with Audacity, Part 1 (link
>>>             <http://www.jtoolkit.com/audio/Audacity_Guide.pdf>) &
>>>             Part 2 (link
>>>             <http://www.jtoolkit.com/audio/EditingAudioPart2.pdf>).
>>>
>>>               * Published together in 2009 and labeled as a set in
>>>                 Part 2.
>>>
>>>         /Gregg/
>>>
>>>         --
>>>         <oracle_sig_logo.gif> <http://www.oracle.com/>
>>>         Peter Korn | Accessibility Principal
>>>         Phone:+1 650 506 9522 <tel:+1%20650%20506%209522>
>>>         OracleCorporate Architecture Group
>>>         500 Oracle Parkway | Redwood City, CA 94065
>>>         ------------------------------------------------------------------------
>>>         Note: @sun.com <http://sun.com/>e-mail addresses no longer
>>>         function; be sure to use:peter.korn@oracle.com
>>>         <mailto:peter.korn@oracle.com>to reach me
>>>         ------------------------------------------------------------------------
>>>         <green-for-email-sig_0.gif>
>>>         <http://www.oracle.com/commitment>Oracle is committed to
>>>         developing practices and products that help protect the
>>>         environment
>>>
>>>     --
>>>     <oracle_sig_logo.gif> <http://www.oracle.com/>
>>>     Peter Korn | Accessibility Principal
>>>     Phone:+1 650 5069522 <tel:+1%20650%205069522>
>>>     500 Oracle Parkway | Redwood City, CA 94065
>>>
>>>     <green-for-email-sig_0.gif>
>>>     <http://www.oracle.com/commitment>Oracle is committed to
>>>     developing practices and products that help protect the environment
>>>
>>>
>>>     --
>>>     ---------------------------------------------------------------
>>>     Loďc Martínez-Normand
>>>     DLSIIS. Facultad de Informática
>>>     Universidad Politécnica de Madrid
>>>     Campus de Montegancedo
>>>     28660 Boadilla del Monte
>>>     Madrid
>>>     ---------------------------------------------------------------
>>>     e-mail: loic@fi.upm.es <mailto:loic@fi.upm.es>
>>>     tfno: +34 91 336 74 11
>>>     ---------------------------------------------------------------
>>>     --
>>>     <image001.gif> <http://www.oracle.com>
>>>     Peter Korn | Accessibility Principal
>>>     Phone:+1 650 5069522 <tel:+1%20650%205069522>
>>>     500 Oracle Parkway | Redwood City, CA 94065
>>>     <image002.gif> <http://www.oracle.com/commitment>Oracle is
>>>     committed to developing practices and products that help protect
>>>     the environment
>>>
>>> --
>>> <image001.gif> <http://www.oracle.com>
>>> Peter Korn | Accessibility Principal
>>> Phone:+1 650 506 9522 <tel:+1%20650%20506%209522>
>>> OracleCorporate Architecture Group
>>> 500 Oracle Parkway | Redwood City, CA 94065
>>> ------------------------------------------------------------------------
>>> Note: @sun.com <http://sun.com> e-mail addresses no longer function; 
>>> be sure to use:peter.korn@oracle.com 
>>> <mailto:peter.korn@oracle.com>to reach me
>>> ------------------------------------------------------------------------
>>> <image002.gif> <http://www.oracle.com/commitment>Oracle is committed 
>>> to developing practices and products that help protect the environment
>>
>
> -- 
> Oracle <http://www.oracle.com>
> Peter Korn | Accessibility Principal
> Phone: +1 650 506 9522 <tel:+1%20650%20506%209522>
> Oracle Corporate Architecture Group
> 500 Oracle Parkway | Redwood City, CA 94065
> ------------------------------------------------------------------------
> Note: @sun.com e-mail addresses no longer function; be sure to use: 
> peter.korn@oracle.com to reach me
> ------------------------------------------------------------------------
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
> developing practices and products that help protect the environment

-- 
Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 506 9522 <tel:+1%20650%20506%209522>
Oracle Corporate Architecture Group
500 Oracle Parkway | Redwood City, CA 94065
------------------------------------------------------------------------
Note: @sun.com e-mail addresses no longer function; be sure to use: 
peter.korn@oracle.com to reach me
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment
Received on Tuesday, 11 September 2012 22:24:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 September 2012 22:24:42 GMT