Re: Web Standards and the new layout

[Jeff Waugh <jdub perkypants org>]

<quote who="Brian Kerrick Nickel">

> First and foremost, the main navigation has been placed at the bottom of
> the page, instead of the top (where it appears), causing an accessibility
> problem for people on lynx, screen-readers, etc. I read that this was for
> the benefit of search engines, but that really isn't the best approach.

Someone has been telling you furphies, because (somewhat regrettably), none
one has paid any attention to search engine issues so far. If anyone would
like to propose goals for meta tags and such, or provide some suggestions on
that front, it would be greatly appreciated.

In fact, the markup design was done specifically *for* a11y reasons, and has
had positive input from Bill Haneman, as well as testing with a number of
blind and partially-sighted users. [1] Much of the disagreement with this
choice has been a matter of 'the sighted leading the sighted', so I'm more
inclined to listen to the ecstatic response it has received from users of
screen readers and text browsers. :-)

  [1] All of whom pointed out the problems with the grey navigation headers,
  regarding markup and choice of colour, btw. Well, at least the partially
  signted users anyway. :-) Those bits will definitely be changing ->
  suggestions? Only one specification: No, don't use the header colour. :-)

The primary reason behind that element of the design is that content
matters. How many pages in a site are designed solely for navigation?
Certainly the site map, hopefully the 404 page, the search page, and
arguably, the front page. Everything else is content driven.

As sighted users, we can very easily ignore blocks of irrelevancy, such as
the navigation areas on a webpage. We can focus on the content immediately,
with very little cognitive interruption. Unless of course the content or
navigation areas are exceedingly unclear, but that's a different problem.

Most screen readers, however, read the entire page top to bottom. So on a
site like, say, www.go-mono.com (sorry dudes, it's a good example), EVERY
PAGE VIEW will result in the screen reader saying, at hundreds of words per
minute:

  home slash mono mono-logo home faq news archive screenshots team other
  sites old news mono runtime embedding classes gtk hash asp stop net ado
  stop net c hash compiler v b compiler download c v s access anon c v s
  access contributing hackers documentation class docs test suite mono todo
  tools porting power p c howto resources beginning mailing lists ideas
  passport books papers languages debugging plans ado stop net
  providerfactory firebird interbase i b m d b 2 microsoft s q l server my s
  q l o d b c ole d b oracle postgres q l s q l lite sybase t d s generic
  crypto java windows stop forms class status corlib system x m l data
  drawing web web stop services microsoft stop visual basic windows stop
  forms enterpriseservices formatters stop soap c s comp m g d system stop
  security contact rss (content starts here, will be different for each
  page) ximian announced the launch of the mono project, an effort to create
  an open source implementation of the stop net development framework.

There are some screen readers that include smartypants heuristics to ignore
the massive chunks of duplicate navigation, ads, and so on that sighted html
designers put into their pages. However, they are expensive, and I don't
believe any FOSS project has started doing this (though w3/emacspeak may do,
I'm not sure).

Regardless, to a text browser or screen reader user, having all of this crap
in the way is a massive inconvenience, if not a huge congitive barrier to
entry. So I disagree with you on this point. It was designed with a11y very
much in mind. :-)

However, as much as I am dedicated to making the site usable and accessible,
this particular feature does cause some problems for the page layout, which
may end up being a higher priority. James Henstridge has been working on the
CSS and layout to help with this, so I hope this helps define the goals and
a11y issues behind what appears to be reasonably crackful from the outside.
;-)

And hey, Telsa really likes the new layout in lynx, so there'll be blood on
the streets if we have a lynx/a11y regression now. ;-)

> The page lack a <h1 />.

Actually, lots of pages do, because the content is exactly the same as it
used to be with the old design (only the layout was changed), which had
hideous graphical headers on every page.

> For this site, the ideal H1 would be the gnome
> icon itself (actually, its alt), along the lines of:
> <h1><a href="http://developer.gnome.org/";><img
> src="/images/gnome-64.png" alt="GNOME Development site" /></a></h1>
> Dropping the image's id and placing the rules on the h1.

Yeah, could definitely do this, at least on the front page. Doesn't make
sense elsewhere though. The front page is going to change (yet again), so
I'll keep this in mind for the logo - it makes a heck of a lot of sense.

> <p class="none"></p> serves on purpose for the document's content and
> should be removed.

Heh, that was never really meant to make it in, but now that you mention it,
I can see it's in all of the sites that use the new design. Oops. ;-) It was
a silly hack to get a linefeed in lynx, believe it or not!

> <p class="section">Navigation</p> should be <h3>Navigation</h3> as it is
> in fact a heading. To keep the size the same, h3 { font-size: 100%; }
> will do the job.

Yeah, think I mentioned that above. Will definitely do.

> I'm not sure a definition list is the right way to present the link
> list, but creating a new list for each pair is really pointless.

Not sure what you mean by 'pair' here, say again?

> Now for some nitpicking:
> There is a real overuse of the ID attribute. CLASS is the ideal
> attribute for CSS formatting as it is more general and can be reused.

I think the use of id is pretty well justified in this context, given that
every element with an id is actually unique. We use classes where there are
multiple uses of that style, id when we are dealing with a specific page
element. We could make more use of selectors, depending on compatibility,
and the header needs some work as described above.

> This may just be me but I think that whitespace in visible elements
> should be maintained in the code, so all these line breaks in sentences
> should be removed.

Yeah, they're just remnants from the unmaintained and uglified html content.

> The copyright <div> should be referred to as a footer, as it contains
> more than a copyright.

Bah, semantics! :-) This has history again; the original footer was removed,
but the copyright bits stayed, so the name stuck. Looking at bugzilla, there
is still room for a footer (even though there are some annoying layout
issues with small pages), so it might return. ;-)

> The community at http://www.DHTMLCentral.com/forums/ is very good when it
> comes to web standards issues. They would be an excellent group to help
> review and perfect code and accessibility issues (except Tim Scarfe really
> isn't a fan of GTK+, so watch out for him).

Not the sighted leading the sighted again? ;-)

Thanks for your feedback and great suggestions!

- Jeff

-- 
Get Informed: SCO vs. IBM                            http://sco.iwethey.org/
 
                I get my kicks above the .sigline, sunshine.