Accessibility Problems with LiveSite generated html

Hello,

We are using TeamSite 6.7.1 with LiveSite 3.0.2 to reconstruct a site that has to be WAI AA-compliant.

We have started making a test page with just static header and menu in a test template, and used the LiveSite "Generate HTML" function. The problem is that the html appears with styles coded in the html. This styles are those to position the components as made through the drag and drop. It also includes a Javascript.

This makes our html code not accessible, so we need to know if there's a way not to generate these styles or a way to edit templates without drag and drop, just by code.

Other option could be to use LiveSite to render TPLs, but I don't know if this is possible.

Any ideas or suggestions would be appreciated.

Thanks a lot.

Find more posts tagged with

Comments

buddha1

Hi sesteban,
I am not sure whether i understood your question or not.

you already designed a component or having problems in creating a component?
if you are having problems in creating, then try using CDATA for the java code and style sheets.

Thanks

sesteban

Hi,

We already created the components. The problem is with the code the drag and drop tool inserts amongst the components.

As long as you can drop the components anywhere, that positions get hardcoded in the .html. I was expecting the drag and drop to receive a configuration file where you establish the places for the components related with your css classes, but it seems there's no way to establish these possible places, and instead of that, components can be placed anywhere.

In this way, the generated .html gets styles hardcoded, and not referring to the css.

I hope I explained better than before.

Thanks,

rexstaples

While 3.1 provides support for digesting the layout css externally, in 3.0.2 the process may be more difficult. There is support for creating a custom page type [pagetype-config.xml] that has its own Java class that runs to generate the html markup in conjunction with an XSL stylesheet.

Create a new layout that extends one of the layouts (for example, com.interwoven.livesite.layout.impl.DivLayout) and instead of returning an interim xml document that gets further fleshed out by com/interwoven/xsl/runtime/div-layout.page.xsl I would push as much of the further processing of that xsl into the Java class (it isn't doing too much additional transforming in there).

Once you have digested the XSL processing into the Java class you will need to select all nodes that have a style attribute. Iterate through that node set and remove the style attribute, assign a unique html id, and then write to a buffer a css rule that uses the unique html id as the selector and binds to it the style rules that you removed from the node.

Write the buffer to disk as a css file, and then provide a link in to the css in your page. You will still pass your Java xml layout to an XSL file, so you could use that as the spot where the css file is linked to the page.

sesteban

This helps us a lot in order to decide whether we're using Site Publisher and LiveSite or not.

Since we are not upgrading to LiveSite 3.1, we are going to use just TeamSite.

Thanks a lot,