Server Side techniques discussion from F2F

At the F2F meeting in Bristol, we broke out into smaller groups to discuss
techniques for various technologies.  I'm sending along the notes from the
server-side discussion.  We spent the bulk of our time brainstorming on
ideas for server-side techniques for sending user-optimized content, and
came up with quite a few.  We discussed how to make accessible the process
of switching between different versions of server-rendered content, and came
up with a new guideline to address this situation.  I will be sending more
detail on the new guideline in a separate mail.  And, of course, we came up
with some issues and questions.

Participants in the discussion were:  Kynn Bartlett , Andrea Snow-Weaver,
Lisa Seeman, Dick Brown, Cynthia Shelly, Kazuhiro Kitagawa, and Masafume
Nakane
Disclaimer:  I've filled in our somewhat sparse notes from memory. Please
let me know if I've misquoted you. 

[New Guideline] 
When multiple interfaces are provided, the mechanism for switching between
interfaces must be accessible and easy to find.
Note: more on this in a separate mail

[Techniques]
The general idea behind using the server to enhance accessibility is that
you can use logic running on the server to send content that is optimized
for the user in some way, rather than sending the same markup to all users
and letting the browser sort out what to do with it.  Here are some ideas on
ways that content could be tailored to a user's needs by a Web server.

1.) Browser sniffing [applies to GL 4, GL 1]
Provide an else clause in your conditional script to send "simple" linear
html.  If you are sniffing browsers and sending browser-optimized content
down the wire, you must send generic content to any browser you don't
recognize.  You must not send a "get a new browser" message to a browser you
don't recognize.  Table-free HTML 4 would be a good choice.  [CS adds that
this might also be a guideline, or at least a tech specific normative
thingy]
ISSUE: no way to detect many UA settings from server.  For example, you
can't tell client script has been disabled in a UA that supports it.

2.) Use personalization/content negotiation to provide appropriate
alternatives (this was controversial)

3.) Personalization/Customization [applies to GL 4, GL 1]
a.) allow the user to chooses interface that works for his/her needs.  This
might include color settings, font sizes, compactness of layout, order of
elements, optimized for voice, optimized for small screen, reading level,
size/quality/quantity of graphics, and lots of other stuff.
b.) use cookies save the user's selection, and script (client and/or server)
to automatically give the user this version every time.
ISSUE: privacy concerns about saving info about disability in a cookie.
IMHO (I don't remember if this was agreed on by the group), the concern
should be less if you talk about features like in item "a" above and avoid
having a setting like "this is the blind page"

4.) Generate Separate Accessible page from the same data [GL2]
This allows the site owner to keep the fancy site they have, and create a
very well optimized WCAG site parallel to it, without concern for the
content on the 2nd page becoming stale.  
CAUTION: accessible page not just "blind people page".  Kynn has noticed a
misconception among web developers that screen readers are the only thing
you need to worry about on an accessible page.

5.) Store content separate from presentation in data storage (database, xml,
etc) [GL2]
a.) make sure there are fields in your database for alternative content
(such as alt text) [GL1]
b.) Store metadata (RDF, Schema, DTD, etc)

6.) Use server side scripting to enhance navigation [GL4]
a.) build navigation elements with templates used by many pages to aid in
consistency.  Use variables for page-specific details, and populate them
from a database, xml file, the url of the page, or whatever makes sense.
This approach will allow a change to navigation in a single file to be
reflected across the site, ensuring that navigation stays consistent even
when you change it.  This has an added benefit of making site updates easier
and cheaper.
b.) One of the page-variables should indicate the user's "location" within
the site.  For example, in a tree based navigation structure, mark the
location of the current page in the tree.
c.) re-arrange page elements based on user preferences.  If you have logical
divisions in your page reflected in navigation templates, you can use script
to re-order them.  For example, you could allow a screen reader user to move
navigation elements to the bottom, so the page-specific content would be
read first.
d.) [CS adds that these settings can be persisted (in cookies or database),
or they can be selected from a link on every visit to the site.]

7.) Use server scripting to enhance comprehension [GL3]
a.) allow user to choose from multiple versions of stored content (for
example, different reading levels, or summary vs. full text)
b.) Chunking [GL3, GL4]
Store content in small chunks in database or xml.  Use server script to
assemble them in different ways (long scrolling pages, or wizard-like
shorter pages with script-built navigation between them), based on user
preference or screen size.

8.) Search engines/indexing [CP 4.2]
a.) use server script to create site index or site map
b.) use an ASP (application server providers) who can provide accessibility
features for search. Building a search engine that is tolerant to user error
(spelling etc) is a fair bit of work.  An ASP who specializes in searching
may have already done that work, and could provide it to you as a service
for your site.

9.) Use browser sniffing for bi-directional languages to determine if
logical or visual bi-di is used [GL1, GL6]

[Issues]
May need "override" for 2.1 to provide non-standard markup to non-conformant
user agents for backward compatibility [GL6]

[Questions]
Do guidelines apply not only to "authors", "designers", "interface
creators", etc., but also to all "content providers"?

[stuff that would be nice for content negotiation:]
settings in cc/pp for font size, voice UI, etc
sending browser script setting over the wire
sending OS accessibility settings over the wire (perhaps via cc/pp)

Received on Friday, 13 October 2000 00:28:53 UTC