Re: portals

Well, nothing needs to be done differently from producing accessible 
stuff in general, but there are a few things to keep especially in 
mind...

You are essentially trying to provide access to a lot of information. 
Some relevant checkpoints from WCAG 1.0 and some (personal, of course) 
thoughts on applying them:

Tables:
5.1  For data tables, identify row and column headers.
 
 Tables are a good way to organise information, but you need to make 
them right. As well as th elements in appropriate places, think about 
how the table will read...
 
5.2  For data tables that have two or more logical levels of row or 
column headers, use markup to associate data cells and header cells.
11.2  Avoid deprecated features of W3C technologies.
5.5  Provide summaries for tables.
5.6  Provide abbreviations for header labels.

Or maybe a flatter structure:
3.5  Use header elements to convey document structure and use them 
according to specification.
3.6  Mark up lists and list items properly.

The following really should be obvious...
13.5  Provide navigation bars to highlight and give access to the 
navigation mechanism.
13.6  Group related links, identify the group (for user agents), and, 
until user agents do so, provide a way to bypass the group.

Especially for Portals: 
13.7  If search functions are provided, enable different types of 
searches for different skill levels and preferences.
 
Essentially a portal IS a search function. One trick is to allow for 
broad searching and for deep searching - different people find 
different approaches more successful. There is research by Inmaculada 
Fajardo that you could quote here: 
 http://www.ugr.es/~ergocogn/articulos/towards.pdf as a semi-random 
starting point...

This is the sort of thing that people use semantic web techniques for - 
having something as simple as Dublin Core metadata about the things you 
are pointing to means you can build portals that provide multiple paths 
to the same information - optionally giving people the choice to switch 
between different restricted sets. See also 13.9  Provide information 
about document collections (i.e., documents comprising multiple pages.) 
and 13.2  Provide metadata to add semantic information to pages and 
sites.

Doing this is also helpful because you can export your information 
directly to other systems - allowing people to build the functionality 
of your portal into things they already use. One approach to this is 
the work done in Amaya derived from the Annotea project, which is 
essentially about bookmarks (or personal portals if you prefer to think 
of them that way). A somewhat technical explanation is at 
http://www.w3.org/2003/07/Annotea/BookmarkSchema

Writing style is important - enough information and not too much is a 
hard thing to measure, but important.
13.8  Place distinguishing information at the beginning of headings, 
paragraphs, lists, etc.
12.3  Divide large blocks of information into more manageable groups 
where natural and appropriate.
13.1  Clearly identify the target of each link.
14.1  Use the clearest and simplest language appropriate for a site's 
content.
14.2  Supplement text with graphic or auditory presentations where they 
will facilitate comprehension of the page.
Icons that can be understood on their own are notoriously hard to make, 
but can be helpful if used with other cues. For an extreme example 
(designed for people who have minimal reading skills) see 
http://www.peepo.com
 
And when you've got this right, done the obvious things (valid code, 
text alternatives, not relied on javascripts or Flash or something) 
then you just go through the checklist - 
http://www.w3.org/TR/WCAG10/full-checklist.html - for things you may 
have missed.

It seems daunting the first time, but you get used to it pretty 
quickly. Then the trap is thinking you know what you're doing and 
forgetting to check (at least that's a problem I find is hard to avoid, 
which is why I still check everything. Even if I know I haven't one 
everything I often find simple stuff I can do quickly to make things 
better).

Oh, talking to users is helpful. There are lots of different users of 
course, so you need to be sure that you aren't just listening to a 
couple of sides of a complex story, but adding a couple of random 
insights to what you already knew isn't necessarily a bad thing...

cheers

Chaals

On Wednesday, Oct 8, 2003, at 09:33 US/Pacific, FOX, Jake wrote:

>
> Hi guys,
>
> does anyone know if there are any specific accessibility issues to 
> keep in
> mind when producing a web portal?
> Does anything need to be done any differently?
>
> All feedback is very much appreciated.
>
> Many thanks,
>
> -Jake.
>
> --------------------------------
> Jake Fox
> Web Analyst
> Group Web Solutions
>
> Norwich Union
> Floor 3 - East Wing
> Sentinel House
> 37 Surrey Street
> Norwich
> Norfolk
> NR1 2UZ
>
> Tel: +44 (0)1603 686333
> Fax: +44 (0)1603 840618
>
> email:         foxj@norwich-union.co.uk
> website:     http://www.norwichunion.com
> intranet:      http://websolutions.intra.norwich-union.com
>
>
>
>
> **********************************************************************
> This email and any files sent with it are intended only for the named
> recipient. If you are not the named recipient please telephone/email
> the sender immediately. You should not disclose the content or
> take/retain/distribute any copies.
> **********************************************************************
>
>
>
> Norwich Union Life & Pensions Limited
> Registered Office: 2 Rougier Street, York, YO90 1UU
> Registered in England Number 3253947
> A member of the Norwich Union Marketing Group
> Members of which are Authorised and Regulated by the Financial 
> Services Authority.
>
> For further enquiries 01603 622200
>
>
--
Charles McCathieNevile                          Fundación Sidar
charles@sidar.org                                http://www.sidar.org