Dynamically Generated Pages (taking it to a wider audience)

Hello,
Right after the face-to-face in LA, Frank and I started this discussion on
how best to take advantage of server-side content generation to aid
accessibility.  We haven't had much of a chance to progress on it, so Wendy
asked me to send it to the list for further discussion.
I'm interested to hear the thoughts of the broader group on this topic.
Thanks,
Cynthia
-----Original Message-----
From: Cynthia Shelly 
Sent: Friday, April 21, 2000 7:25 PM
To: 'Frank Torrey'; Rebert Neff; 'Kynn Bartlett'
Subject: Dynamically generated pages [WAS: Hello There]
Hi All, 
This came up as an outstanding action item at the conference call today, and
I promised to ping you guys, and see what we could do to get it moving... 
Based on recent discussions of how to generalize the guidelines, and move
technology-specific stuff to multiple techniques docs, I think what we're
writing here is the techniques doc for dynamically rendered content.
Agree/disagree? 
One approach we could take is to look at all the Accessibility Themes (from
the version 1.0 techniques doc) and come up with ways to address them from
the server side. I also like Frank's 4-tier approach below, but I'm not sure
how to integrate the two. Thoughts? 
Here's a brain dump of how each of the themes could be addressed with
dynamic content. Many of these assume that content negotiation is available
and that we know that a user wants a particular type of content. This can be
accomplished in the short term with cookies, but ccpp might be a better
solution for the future (I still need to read all the way through the note).
Ponderable: How could User Agents identify their level of support for
various accessibility features? Maybe http headers, but that could get ugly.
Would cc/pp be able to do this? 
3 Accessibility Themes 

3.1 Structure vs. Presentation 
In the dynamic case, these are inherently separate. The structure is held on
the server side in a database, xml file, etc., as is the content.
Presentation is added at Frank's tier 3, either with programmatic script
where each possible setting is a branch or series of branches, or with
appropriate XSL transformations for the user in question. 

3.2 Text equivalents 
This one can be done the same way as client/html solutions with alt text
(probably easiest), but if we're doing content negotiation and we know (for
example) that we're talking to a blind client, we could simply replace the
images with text, not have to worry about downloading the images, and
optimize the resulting HTML for audio presentation. 

3.3 Alternative pages 
We can redirect all over the place on the server to make alternative pages
integrate seamlessly into the site. More interesting is alternative chunks
of content, or alternative layouts on the same content, or some combination
of the two. 
3.4 Keyboard access 
In the short term, I think this one is the same as the HTML recommendation,
since keyboard interaction is all done client-side. However, we could add
extra keyboard shortcuts, additional help for keyboard users, etc, based on
user settings. 

3.5 Navigation 
If we know what the user is looking for, there are some super-cool things we
can do here. Navigation optimized for an auditory interface, or a cell
phone, or a Cognitively Disabled user, would be very different from
"standard" gifs 'n' links navigation. 

3.6 Comprehension 
There have been some interesting threads on the alias about this one.
Jonathan's idea of summarized content is easier in a databasey world than in
a pure markup world, as there can be snippets at various reading (or
non-reading) levels can be stored and assembled on the fly. Of course there
are still significant production cost issues here that we need to be careful
of. For example, localized sites might have to build 3 reading-level
versions in 64 languages. If they can't afford that, do we end up with only
grade-school level content in some languages? Or sites translated into fewer
languages? There are a lot of issues here that need to be worked out here,
which have huge and far-reaching implications. 
Frank's idea of chunking content based on a user setting is pretty cool, and
is cheaper, easier, has fewer far-reaching implications than summarized
text. 

3.7 Content negotiation 
right now we can do some things with cookies to pick appropriate content,
but the user will have to set this up through author-provided UI. This could
be pretty tough for CD people, old ladies, etc., and would have to be set up
at each site. yuk. Once again, hoping ccpp can help with this. Might be an
interesting thing to discuss with the UA WG as well, as it would be neat to
set this stuff once in the browser. 

3.8 Automatic page refresh 
use server-side redirections. duh. 

3.9 Screen flicker 
not really relevant 

3.10 Bundled documents 
not sure how/if this applies. Offline reading of dynamic content is also a
pretty sticky area. We should do some thinking on this one. 

3.11 Validation 
This one is kind of sticky. Of course you can run validators on the final
output, but they won't know that their looking at one optimized view of the
data, and will likely complain. Architectural design reviews, and lots of
black-box testing and usability studies with disabled users seem like the
only viable ways to validate that a server-side solution meets all the
needs. It's a difficult thing to automate. One possibility: If we have a
known set of user-settings (big if), a script could be built to hit the site
with each of them, but how could you verify that the sum of all the versions
was accessible to everyone? We should do some brainstorming with the ER
group on this. 

3.12 Browser Support 
We get a lot of wiggle room here by going to the server. We can identify
browsers that support newer accessibility features, send them the cool
stuff, and for older browsers either ask the user or send plain-text or
simplified html versions. 
Thoughts? Comments? Additions? 
Cheers, 
Cynthia 
-----Original Message-----
From: Frank Torrey [mailto:thefrank1@home.com]
Sent: Thursday, April 06, 2000 3:46 AM
To: Cynthia Shelly; Rebert Neff; 'Kynn Bartlett'
Subject: Re: Hello There

	I think you hit both areas there. We're talking about alternative
content and it seems, given the page based nature of the web, that leaves
you with alternate entire pages or alternate pieces of pages. The actual
content of either solution would ideally be determined by user need (through
usage habits, manual settings (per site, personal profile), generic
defaults, user agent identification (device and software level), the list
could probably go on). The real point here, and perhaps the reason that
we're even doing these guidelines, is that there would no longer have to be
a single page that accommodates all user needs. All users can be
accommodated through "smart" serving. Overall, the current guidelines bring
to light and address a broad range of needs through content recommendations.
The rules still apply, just in subsets. At any rate, with the content in
place, generating a single version that met all GLs probably wouldn't be too
hard anyway (in fact the ability to generate such a version could be a
checkpoint, whether you actually provide the version or not). 
	You can blend the lines of alt pages vs. alt pieces by responding to
a user need of delivering pieces of a page as smaller pages. This would in
effect be like mini alternative pages that require some sequence of
navigation to get the same meaning (maybe useful for blind users, CD users,
or even a tired user who wants fewer decisions). This demonstrates an
interesting point. The boundary (or scope) of a "page" can become much more
flexible. From a design perspective this still follows the rule of ensuring
good linearization of information, whatever the linear path may be (perhaps
even altered as one navigates). 
	For the generic model end of things I'm seeing four basic parts so
far: 
		Source content - set up in a such a way to serve a variety
of user needs (XML single source, DB, Xlinks to distributed content, etc) 
		User needs - (determining them) could be general groupings
of needs (deaf user) or very specific (provide subtitles for all
non-English/French movies). The degree of granularity might be determined by
the providers of the site just as long as there is a version for everybody 
		Mechanism to put together content (from 1, based on 2) with
a useful markup - content could be either "packed" with the page or linked
in somehow. Additional navigation may also need to be generated 
		End content (output of 3) - as it is presented to a user
This is certainly not to say that implementations wouldn't blend these
lines, just that these are the conceptual lines I'm toying with. 
	Enough for now :) 
	-F- 
		-----Original Message-----
		From: Cynthia Shelly <cyns@microsoft.com
<mailto:cyns@microsoft.com>>
		To: 'Frank Torrey' <address deleted> Rebert Neff <address
deleted> 'Kynn Bartlett'<address deleted>
		Date: Wednesday, April 05, 2000 7:44 PM
		Subject: RE: Hello There
		
		I like the idea of making the document as generic as
possible. I also think we need to get into the specifics of server-rendered
sites in areas where the solutions you choose for a server-rendered site
would be different than those for a static HTML site. 
		The issue brought up on this list a few weeks ago about
"ghetoization" (sp?) and content not being updated on secondary pages is
very different in a dynamically generated environment. It's also possible
through cookies (and I hope someday content negotiation with standards-based
headers) to replace the regular page with the alternate one for a particular
user. This isn't true on a static site. Similarly, sections of the page can
we tweaked to user settings in a dynamic environment, without creating a
whole separate page. This is alternate content without an alternate page. 
		I'd like to start by coming up with a list of these types of
solutions that aren't addressed by the existing guidelines. What are some I
haven't thought of? 
		cheers, 
		Cynthia
-----Original Message-----
From: Frank Torrey <address deleted>
Sent: Wednesday, March 29, 2000 1:34 AM
To: Cynthia Shelly; Rebert Neff
Subject: Hello There
Any body have any ideas on where to start with this proposal for the WAI? 
I've been thinking about it and it seems that Gregg Vanderheiden is right
when he says that the question isn't how, but what. And the notion of
accessibility does not have to pertain just to disabilities. I think the
next wave of web usage (if not held up by lack of collective effort) will be
in the mobile/wearable arena. What once was the need of a small market
becomes the need of a growing mass. 
Using this logic our guidelines could be something along the lines of the
XML accessibility guidelines. Perhaps we could expand this to focus on a
generic model that lends itself to rapid accommodation of new markups
through back-end source control (XML, DB, or whatever). End content is
already taken care of in the current guidelines. If we frame our document
right in an abstract or exec summary it could have a much more attentive
audience! Remember, what comes out of the of this group often goes to
authoring tools group (among others). 
I'm starting to work out some ideas but don't want to get too far ahead of
myself without the rest of you. 
BTW, either of you have Kynn's email? didn't get his card. 
Frank Torrey 
Webmaster/Graphic Designer 
Duxbury Systems, Inc. 
(608)257-9595

Received on Thursday, 6 July 2000 21:49:24 UTC