new css help site

[trinzia]

Hi,
I made this site: www.pixielounge.com.

It's for help on some commonly asked questions, especially in CSS, so I just thought I'd let someone know it's there. None of the code is copyrighted, it's all (I hope) tested in Firefox and IE, and all in valid doctype declarations (no quirks mode). I also tried to make all the designs handicapped-accessible, but I am still working on that in a few cases.

If you have constructive criticism I will of course be glad to hear back.


Trinzia

[Twey]

XHTML allows more types of browsers to correctly read your code.

Wrong This may become true in the future, but as it stands, XHTML is significantly less accessible than HTML, and so should not be served to clients. See http://www.hixie.ch/advocacy/xhtml.

all in valid doctype declarations

But it's XHTML Transitional. XHTML issues aside, Transitional DOCTYPEs should not be used on a permanent basis. As the name implies, they are intended as a stepping-stone to a modern, standards-compliant site. In fact, because people are using Transitional DOCTYPEs even for new sites, the W3C hasn't produced a Transitional version of XHTML 1.1.

[Accessibility] should also be a major concern for retail sites.

It should be a major concern for everybody.

I started searching on accessibility (Section 508), and realized I need to stop doing page layout with tables. But how?

By using CSS, as was intended

Also, your sidebar does not increase in width when needed, and with Javascript off it overlaps with the header at some resolutions. On top of this, your resumé (yes, not "resume" ) is in Flash, without any static fallback, and so totally inaccessible to anyone without Flash.

[trinzia]

I have not tested the html4 doctype - does it eliminate quirks mode? That was my main intention - to have all the pages work without quirks mode.

I chose Xhtml because I want my code to parse as Xml would -- would that be valid markup in html4 too? ie <br />? There are some very good reasons to have your html pages also be Xml, but that could turn into a long discussion.

I will read up on the difference between transitional and strict though, thank you.

~trinzia

[Twey]

I have not tested the html4 doctype - does it eliminate quirks mode?

Of course it does.

I chose Xhtml because I want my code to parse as Xml would

Why?

would that be valid markup in html4 too? ie <br />?

Yes, although it wouldn't have the same meaning. Read the link above.

In addition, your non-Javascript menu uses an iframe, which is not valid in a Strict DOCTYPE (and indeed, you said that you were attempting to avoid them).

/EDIT: In fact, it doesn't validate either.

[trinzia]

Point taken. I need to spend more time on the actual site setup, and I will tomorrow. It used to validate but I broke it apparently.

More important are the sample files... you feel strongly they should be in html4 doctype? I am far more concerned about those than about my site, which is just a shell for those.

My reasons for wanting the pages to parse as xml were:

1. Shockwave will be able to import and parse Xhtml but not Html, allowing for more fluid & accessible content in SWFs. http://www.adobe.com/devnet/logged_i...mbers_xml.html
For example, you have a test with 20 questions, you want them shuffled and presented in random order. Some of the questions are drag/drop items into their correct locations, some are multiple-choice. Wouldn't it be nice to keep the questions in Xhtml format, but have the test in SWF? Not sure that I'm going to get that working, but you get the idea. I had it working in Xml but, oh it's a long story.

2. Anyone working with Scorm is already doing Xml, and Xhtml seems more likely to be compatible with Scorm 2004 (& future versions), especially regarding supplemental navigation.

3. I assumed that palm pilots & cell phones (I don't own one, so I cant test it) would do better with Xhtml since everyone says so.

4. Some pages use XML feeds to import content from other pages.

With those things said, I am willing to be convinced that you are correct...

Here's a question for you: what do you suggest for someone making a site under these restrictions?

1. No server access, period.
2. No frames allowed.
3. Hierarchical navigation with persistent menu state required. (if user opens and navigates to a page, the tree should remain open.)
4. Must be 100% accessible.

What do you think, can it be done?
Can it be done with cookies?
Can it be done without cookies?

trinzia

[Twey]

My reasons for wanting the pages to parse as xml were:

In this case, you should store the data as XML, then transform it server-side into HTML when the appropriate request is given.

allowing for more fluid & accessible content in SWFs.

SWFs are plugin content, and thus down the far end of the accessibility scale anyway. If you want to be accessible, don't use SWF (or provide alternative content).

Here's a question for you: what do you suggest for someone making a site under these restrictions?

Depends what needs to be done.

3. Hierarchical navigation with persistent menu state required. (if user opens and navigates to a page, the tree should remain open.)

There's no acceptably accessible way to do this. You can always have a fallback, of course.

3. I assumed that palm pilots & cell phones (I don't own one, so I cant test it) would do better with Xhtml since everyone says so.

I wouldn't think so, but I can't be sure since I don't have one either. Content negotiation should help here. The clincher is:

1. No server access, period.

I presume you mean no server-side scripting, since literally no server access would mean you couldn't upload or edit your site This is a big problem when trying to create an accessible site, and I'd strongly advise you to get a decent server that does support server-side scripting in some form.

What do you think, can it be done?

It can be done. The tricky bit is the XML/HTML duality. You may have to use two copies of the site, one in XML or XHTML and one in HTML.

[trinzia]

(No server scripting) is a big problem when trying to create an accessible site, and I'd strongly advise you to get a decent server that does support server-side scripting in some form.

I make many government educational websites, which means that I am not the one in control of the server, rarely even have access to it, and I must conform to Scorm and Section 508 at the same time. I think you'll find that typical of a large number of gov sites.

There are also a large number of designers out there, producing content, who wouldn't know what to do with server access even if they had it. That was my target audience (not the pros with a dozen server programmers in their employ - they don't need a help site, i hope). The issue is 'how can your average Jo best make an accessible site?'

You may have to use two copies of the site, one in XML or XHTML and one in HTML.

Not an option. I simply have way too many pages, into several thousands that I manage. I am thinking of just leaving alot of them in iframes. Can you point to any sites about why iframes would or would not be accessible?

I am also thinking you're right & I will do some more tests on Xhtml with proper mime-type, and/or change all my sample files to html4 doctype.

I'm still left with the major question of how to include a file without using frames, so we don't have to paste a very long menu code into every single page. As you see, I show 3 include methods in my site - which is most accessible you think? php?

[Twey]

There are also a large number of designers out there, producing content, who wouldn't know what to do with server access even if they had it. That was my target audience

Aaah, I see, I thought that you were talking about your own site. I would advise Javascript (which would include cookies, yes), with a static fallback. Depending on the size of the site, an individual copy of the menu could be kept on each page, or a single link could be provided to a "site map" page.

I think you'll find that typical of a large number of gov sites.

Your own site is not a government site, however. There's nothing to stop you moving it to a different machine to which you do have full access.