W3C home > Mailing lists > Public > public-wai-evaltf@w3.org > April 2012

Re: Discussion: dynamic pages

From: Elle <nethermind@gmail.com>
Date: Fri, 6 Apr 2012 14:26:09 -0400
Message-ID: <CAJ=fddPLhWDWiVhgGH-zd=7BXApqDyxy0Adjc9eM9V-o_hC5dQ@mail.gmail.com>
To: Peter Korn <peter.korn@oracle.com>
Cc: "Velleman, Eric" <evelleman@bartimeus.nl>, "public-wai-evaltf@w3.org" <public-wai-evaltf@w3.org>
Peter:

With regards to the list of URLs not being sufficient, that's exactly why I
suggested use cases and I believe why we're having this discussion.  I was
merely pointing out that there is some amount of discussion and
requirements gathering that any auditor must do to effectively test a
website.  During that discussion, any user experience use cases could be
gathered to account for each user profile and scenario.  We won't need all
use cases, but those that account for UX sign-off would help create
accessibility test cases.  We've also used wireframes, but that's really
dependent on how detailed the interactive documentation is on them.


Regards,
Elle




On Fri, Apr 6, 2012 at 1:45 PM, Peter Korn <peter.korn@oracle.com> wrote:

>  Elle,
>
> A full list of URLs won't be enough in all cases.  Many web applications
> use a single URL/URI, yet have a large number of different "screens" that
> they display behind that single URL/URI (using cookies, etc. to track which
> "screen" to generate).  Others dynamically generate the URLs/URIs, again
> making it impossible to provide a list in advance.
>
> Regarding use cases, there is another wrinkle there...  Large web
> applications have many use cases - sets of them in some cases (think of a
> CRM application, or an accounting package).  Any given customer may only be
> using a small subset of those use cases.  Such a customer may not care
> whether some portions of the product they aren't using aren't accessible...
>
>
> Regards,
>
> Peter
>
>
> On 4/6/2012 10:17 AM, Elle wrote:
>
> Peter:
>
> I assume that at the very least, an auditor would need a full list of the
> URLs from the website owner to perform an accurate evaluation.  In keeping
> with that need to communicate with the website owner, requesting use cases
> in addition to URLs seemed reasonable.  The question I have (after thinking
> through this) is, what recommendations would we give auditors for testing
> dynamic pages that don't have any use cases available?  Not every company
> keeps that kind of rigor with their development and requirements tracking.
>
>
>  ~Elle
>
>
>
>
> On Fri, Apr 6, 2012 at 1:04 PM, Peter Korn <peter.korn@oracle.com> wrote:
>
>>  Hi Elle,
>>
>> Just curious - are we presuming that all website evaluations will be done
>> with the knowledge & cooperation of the website owner / developer?  Without
>> that, how could the evaluator determine what the full set of use cases is?
>>
>>
>> Peter
>>
>>
>> On 4/6/2012 6:33 AM, Elle wrote:
>>
>> Eric:
>>
>>  I still believe that we can just model accessibility audits after the
>> business use cases that are provided for a web application's launch.  In my
>> experience, all of these dynamic scenarios are covered when testing web
>> pages for success in meeting functional requirements; each profile has a
>> use case.  All we need to do is write the accessibility audits for each use
>> case.
>>
>>
>>  Thanks,
>> Elle
>>
>>
>>
>>
>>
>> On Thu, Apr 5, 2012 at 11:42 AM, Velleman, Eric <evelleman@bartimeus.nl>wrote:
>>
>>> Dear all,
>>>
>>> I would appreciate your input on what to do with audits of dynamic pages
>>> that do not just change data, but also provide different outputs, layout,
>>> alt-tags etc. Could we cover this by describing the exact use cases that we
>>> followed? But how do you evaluate a page that does this if you are an
>>> evaluator with a different profile than the use case that has been chosen?
>>>
>>> Kindest regards,
>>>
>>> Eric
>>>
>>>
>>
>>
>>  --
>> If you want to build a ship, don't drum up the people to gather wood,
>> divide the work, and give orders. Instead, teach them to yearn for the vast
>> and endless sea.
>> - Antoine De Saint-Exupéry, The Little Prince
>>
>>
>>   --
>> [image: Oracle] <http://www.oracle.com>
>> Peter Korn | Accessibility Principal
>> Phone: +1 650 506 9522 <+1%20650%20506%209522>
>> Oracle Corporate Architecture Group
>> 500 Oracle Parkway | Redwood City, CA 94065
>> ------------------------------
>> Note: @sun.com e-mail addresses will shortly no longer function; be sure
>> to use: peter.korn@oracle.com to reach me
>> ------------------------------
>> [image: Green Oracle] <http://www.oracle.com/commitment> Oracle is
>> committed to developing practices and products that help protect the
>> environment
>>
>
>
>
>  --
> If you want to build a ship, don't drum up the people to gather wood,
> divide the work, and give orders. Instead, teach them to yearn for the vast
> and endless sea.
> - Antoine De Saint-Exupéry, The Little Prince
>
>
> --
> [image: Oracle] <http://www.oracle.com>
> Peter Korn | Accessibility Principal
> Phone: +1 650 506 9522 <+1%20650%20506%209522>
> Oracle Corporate Architecture Group
> 500 Oracle Parkway | Redwood City, CA 94065
> ------------------------------
> Note: @sun.com e-mail addresses will shortly no longer function; be sure
> to use: peter.korn@oracle.com to reach me
> ------------------------------
> [image: Green Oracle] <http://www.oracle.com/commitment> Oracle is
> committed to developing practices and products that help protect the
> environment
>



-- 
If you want to build a ship, don't drum up the people to gather wood,
divide the work, and give orders. Instead, teach them to yearn for the vast
and endless sea.
- Antoine De Saint-Exupéry, The Little Prince


oracle_sig_logo.gif
(image/gif attachment: oracle_sig_logo.gif)

picture
(image/gif attachment: 02-part)

picture
(image/gif attachment: 03-part)

green-for-email-sig_0.gif
(image/gif attachment: green-for-email-sig_0.gif)

Received on Friday, 6 April 2012 18:26:38 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:52:13 GMT