Loading...
 
Skip to main content

Tiki Design


A Big Idea

posts: 3

Hey, folks:

The theme resetter cut me off as I was trying to post before, which kind of underscored my original point. I'll make it brief this time: when it comes to modern standards, TikiWiki's themes are mostly broken. Try plugging any Tiki's URL into the W3C validators and you'll see what I mean. It's even worse if you need Section 508 (accessibility) compliance, as more and more Webmasters do these days.

Enough griping, here's my proposal for a solution. I'm now hacking my way through the massive Tiki stylesheet, trying to generate a fully W3C- and 508-compliant style. It'll be basic, but hopefully I'll be able to get it done so others can work from it. The HTML errors will be harder to fix. I can probably address some of them as I get smarter with Smarty, but eventually we'll need someone with real PHP chops to get interested in this problem.

So, does anyone else want to work on this, or am I on my own?

posts: 26 United States

You're not alone. My Tiki validates both XHTML and CSS.
Additionally, it has a valid P3P policy and aheres to WAI-A compliancy. But it wasn't easy.

Some of the major items I added to my template:

  • Add summaries to all tables
  • For data tables, be sure to assign headers
  • Assign ALTs to every image and field
  • Add access keys for main menu items
  • Add labels to all form elements


HTH,

-Rick

posts: 38 Canada

Some of the major items I added to my template:

  • Add summaries to all tables
  • For data tables, be sure to assign headers
  • Assign ALTs to every image and field
  • Add access keys for main menu items
  • Add labels to all form elements



Excellent!

How about a 508 theme or similar?

Thanks!!

M 😉

posts: 26 United States
How about a 508 theme or similar?


Yup, KC.o passes 508 validation too.

However, making "special" themes that are accessible is (IMHO) a mistake. Every theme should be accessible (be it WAI, Section 508, etc.). To draw a distinction between accessible and non-accessible sites does nothing but create barriers.

There is no reason why accessibility standards shouldn't be followed for ALL sites. Every Tiki should be able to pass:

  • XHTML validation
  • CSS validation
  • WAI-A


Just my $0.02.

-Rick

posts: 38 Canada

There is no reason why accessibility standards shouldn't be followed for ALL sites. Every Tiki should be able to pass:

  • XHTML validation
  • CSS validation
  • WAI-A


Hi Rick!

I agree 100% with the goal. I am just thinking it is easier to start with one and fix the others after.

Can you lead the way?

Related project: http://mobile.tikiwiki.org

Thanks!


M 😉

posts: 26 United States

Hi Rick!

I agree 100% with the goal. I am just thinking it is easier to start with one and fix the others after.

Can you lead the way?

Related project: http://mobile.tikiwiki.org

Thanks!


M 😉


Sounds good. As a beginning, I think we should examine the TPL files for the following:

  1. All tags must be XHTML valid — This means things like replacing all the &ltbr> with &ltbr />
  2. All images must have fixed sizes and valid ALTs
  3. All tables must have a SUMMARY
  4. All data tables must have headers, signifed with &ltth> tags
  5. All data tables must assign column and rows correctly


It is minor things like these that cause so many validation problems.

What theme would you suggest starting with? Is SIMPLE the theme that is loaded, by default, with a new Tiki install?

-Rick

posts: 38 Canada
What theme would you suggest starting with? Is SIMPLE the theme that is loaded, by default, with a new Tiki install?


tikineat.css is the default theme. simple.css is also a good choice to start with because it says in the comment: "We also try to make better templates (*.tpl files in templates/styles/simple) towards xhtml 1.0 strict validity."

posts: 2 None

I don't think we can afford to take care about a couple of css. The th stuff will break some of the themes that don't have a th setting and people will not be happy.

For the styles that are in the code .... I really don't know why - a $smarty->fetch() is so easy to do....

posts: 38 Canada

> #All tags must be XHTML valid — This means things like replacing all the &ltbr> with &ltbr />

This is regularly done on BRANCH-1-9

> #All images must have fixed sizes and valid ALTs

OK

> #All tables must have a SUMMARY

For the FANCYTABLE plugin, we could add a field for Summary, so people can add this when editing a wiki page.

> #All data tables must have headers, signifed with &ltth> tags

I think FANCYTABLE plugin offers part of this

> #All data tables must assign column and rows correctly

OK

posts: 1

Anyone still monitoring this thread? I've (finally) started work on a new Tiki theme. I've based it (loosely) on Google's interface... very clean.

My goals:
- XHTML validation & CSS validation
- WAI-AA validation

Anyone want to help? Contact me directly.

-Rick

posts: 254 Japan

Anyone still monitoring this thread? I've (finally) started work on a new Tiki theme. I've based it (loosely) on Google's interface... very clean.

My goals:
- XHTML validation & CSS validation
- WAI-AA validation

Anyone want to help? Contact me directly.

-Rick


I'm interested, as I've been working with the Simple theme (luci's lite CSS) as a base for my Zuka redesign and will probably base future themes on these files as well. They are table-free so are more advanced in that sense, with CSS validation also a goal. It'd be good to see about collaborating, maybe using common templates, etc. I'll send you an email too, but wanted to make a reply here in case anyone is interested.

-- Gary


posts: 3

Good to know I have company. I started on a "508 theme" right after posting, and quickly discovered that none of the bundled themes even validate as W3C-compliant CSS. Instead, I took the blank stylesheet (which also didn't validate, but was much easier to fix), installed that on my local test Tiki, and started hacking away at it. As we all know, the Tiki stylesheet is an absolute beast, so I don't expect to finish this project right away. This is strictly a volunteer job for me.

This experience makes me think that bringing all of the bundled themes into full 508/WAI (or even just basic W3C) compliance would be a nightmare. Since posting my first message, I've found some old entries in the Wiki that reveal that others have tilted at this windmill before. There was one suggestion that the 1.10 development branch would include only 508-compliant themes, but when I checked a snapshot of 1.10, I saw that isn't happening yet.

So here's my problem: right now, I run a community site using a combination of MediaWiki, Phpbb, and Serendipity. I did that after experimenting with Tiki on my own site (the DogFood principle) and seeing how hard it would be to fix this issue. I really want the unified site design we'd get with Tiki, but we have to make a good-faith effort to be compliant, so MediaWiki et al. won out. Those three apps aren't perfect, but they're much closer than Tiki at the moment.

Given what you've said above about your redesign, it appears that my Tiki is going to need some fixes that go deeper than the CSS. Is an accessibility overhaul really coming in a future release, or should I just jump ship now and head for Plone?

posts: 26 United States

In my opinion, the CSS style sheets aren't the big problem. Most of the errors I've seen are minimal and easily fixed. The big problem (IMHO) is that the TPL files create poorly constructed HTML.

If you're creating your own custom theme, then you've already committed to creating your own TPL templates files. As long as you're doing that, it is nothing extra to add the necessary information to make the files validate properly and be accessible.

The biggest problem that you'll find is that sometimes presentation data is actually hard-coded in the PHP files (argh!).

My personal opinion is that Tiki is great — I love having all the functionality I need (wiki, forums, cms articles, image galleries, etc.) all under "one roof" without having to splice together different pieces. I helps make the site look "unified."

-Rick

Just as an aside.... The Section 508 requirements are for the US. Does anyone know if there are similar requirements for the EU?

posts: 3
In my opinion, the CSS style sheets aren't the big problem. Most of the errors I've seen are minimal and easily fixed. The big problem (IMHO) is that the TPL files create poorly constructed HTML.

That's what I'm figuring out now, which is why I'm trying to sound the depth of the interest in real solutions. It appears that there isn't a serious effort underway on this front yet, so I'm leaning toward dropping the Tiki idea altogether. It has a lot of promise, but this is really a deal-breaker for me.

Just as an aside.... The Section 508 requirements are for the US. Does anyone know if there are similar requirements for the EU?

Yes, there are. I think they're officially called Priority 1, Priority 2, and Priority 3, with a phase-in period for compliance, and they seem to line up more or less with the WAI "A, AA, AAA" ratings.

posts: 38 Canada
In my opinion, the CSS style sheets aren't the big problem. Most of the errors I've seen are minimal and easily fixed. The big problem (IMHO) is that the TPL files create poorly constructed HTML.

That's what I'm figuring out now, which is why I'm trying to sound the depth of the interest in real solutions. It appears that there isn't a serious effort underway on this front yet, so I'm leaning toward dropping the Tiki idea altogether. It has a lot of promise, but this is really a deal-breaker for me.


No serious effort? Rick has succeeded for his site: http://www.keycontent.org/

simple.css is also an effort. And mobile.tikiwiki.org

Let's all work together on this! We can work on one theme and as we solve things, we can port to the general tpls

Best regards,

M 😊