By dennisluitwieler on

Hi,

I hope someone can let me know if my current solution to an accessibility 'problem' is good.

I'm trying to setup the content-type of my pages to make the following possible:
I want to render content that has a title and multiple (theoretically unlimited) paragraphs. Each paragraph should have an optional title and obligatory content. To adhere to accessibility guidelines (SEO -wise) I need to render the heading/title of a paragraph as an HTML header (e.g. h2 or h3). Also I do not want to let the user deal with the complexity of HTML headers.
I cannot create a content-type with only 1 body, because then for each paragraph a user would have to manually type those HTML headers above each paragraph.

For my current solution I found the "field collection" module with which I created a collection-field named "paragraph" that has a title and body, then added this collection-field to my content type and allowed it to have an unlimited amount of paragraphs.
I *think* that I should be able to render these paragraphs in a custom theme with a h2 now (I haven't created a theme yet, so I am unsure of this).

I am wondering if this is this the way to go.
Are there better ways to deal with this, perhaps other modules or configurations I should take a look at?
I would appreciate if someone give me some feedback on this and/or nudge me towards information/documentation for better or alternative solutions.

I am just starting with Drupal, so please ... be gentle :).

⋅ Categories: Drupal 7.x

Comments

markconroy’s picture

markconroy commented

Yes, your solution looks like a very good one.

You might also consider installing the fences module so that you can wrap your headings in H2, H3, etc tags instead of doing it at a theme level.

============

Drupal Core Maintainer for "Out of the Box" Initiative
Annertech - Web Agency of the Year.

dennisluitwieler’s picture

dennisluitwieler commented

Hi Mark, thank you for your response.
I've taken a look at the fences module and it indeed sounds like a great module to give more power over the way fields are rendered.

We are currently in the process of selecting a product that will replace our propriety CMS (Drupal is one of the few candidates still in the race and high on the list) and after our choice we will bring about 25 existing government websites to the newly selected CMS. For each website we'll be creating a custom Drupal theme (seems like the correct approach).

I wonder if a theme wouldn't be a better approach since we'll then be relying on core-drupal instead of a community module which might be abandoned in the future?

Are there any pros/cons using a theme compared to using fences (or alternative modules such as 'field wrappers')?

markconroy’s picture

markconroy commented

In that case (and if you have the resources) if you are thinking 25 government websites, you might as well put it in template (tpl) files.

If you need any more help/info - don't be shy!

============

Drupal Core Maintainer for "Out of the Box" Initiative
Annertech - Web Agency of the Year.

dennisluitwieler’s picture

dennisluitwieler commented

Mark,
Currently technically properly maintaining these (currently about 36) websites is not doable anymore (cut-backs), so moving from our (huge) propriety CMS to an open source solution should help us a lot. For maintenance on the CMS-core and a lot of functionality we can (largely) depend on a community, then depending on our available resources we can build custom modules ourselves or ask other software companies to develop them for us.

In the process we'll be eliminating a lot of our websites. Ideally we'd only have a few of them left, but we've learned things sometimes aren't that ideal :).

Thanks for your help/info.

caschbre’s picture

caschbre commented

I'm not sure field collection is the best option in this situation.

Each item in a field collection becomes and entity. That makes it very heavy as it has to do entity loads for each paragraph. Field collections are more useful when each item in the collection is a reusable piece of content. I'm guessing each paragraph isn't really something you would reuse in this way.

I'm assuming that when you want HTML headers you're referring to the <header> tag? If that's the case you don't need it to be semantically correct if an <hx> tag is the only thing in it. Is the following what you're shooting for with the paragraph markup?

<h2>Some Header</h2>
<p>Here is my paragraph content</p>
<p>Possibly another paragraph</p>

A wysiwyg editor or some other type of markup editor should be able to help the user without them needing to know HTML. You can even provide wysiwyg templates in some editors that let's them choose from a menu and then just type in their content.

-
@foggyperspectiv | foggyperspective.com (blog)

dennisluitwieler’s picture

dennisluitwieler commented

Reusing a paragraph is indeed not something we need.

I was indeed referring to the h1, h2, h3 header-tags. Headers cannot skip a level, so depending on the content-type where the paragraph is used, it could need an h3 in one place and an h4 in another.

Unfortunately it might not be the only thing we need in the content. Other possibles tags will be:
strong, em, anchor
table, ol, ul

These last 3 are pretty complex for most users (esp. since we need to have them accessible).

We haven't yet had the pleasure to work with an editor that actually produces accessible HTML output. Most WYSIWYG editors we've encountered add a lot of extra HTML that break the content in terms of accessibility, so if possible we like to give our users as little markup-power as possible.

caschbre’s picture

caschbre commented

I agree that wysiwyg editors can be painful and messy if not properly controlled. I used various wysiwyg editors to allow the contributor to perform basic tasks like creating lists, marking content as bold (strong), etc. WYSIWYG editors can do these basic things well without mucking up the markup (and accessibility).

What I do is limit what wysiwyg features are available. For example, i'll disable code view and most of the wysiwyg buttons so that a contributor can only do the basics i want to allow. I also use wysiwyg_filter for additional filtering on tag attributes, etc.

Like you said, you want to keep the user out of the markup and make it simple for them to perform basic formatting and I think that can be accomplished.

What may be more difficult is forcing a certain header (Hx) tag. That usually has to come down to training. I restrict the use of H1 since that is usually the page/node title... and leave H2, H3, H4 up to the user to choose at their discretion.

If you need to really force the "cannot skip a level" then you may have to tackle that programmatically. You could validate the content on submission and see if a level is skipped. Or you could try some processing on render that alters a tag (e.g. H4) without a parent (H3).

-
@foggyperspectiv | foggyperspective.com (blog)

dennisluitwieler’s picture

dennisluitwieler commented

Sounds like I would be using some xPath-magic for that.
I've had quite some experience with regular expressions due to a task where I needed to import Word documents (stripping out weird Microsoft-Word characters, converting different types of quotes and bullets to only 1 type (while keeping indentation), converting (un)ordered lists of different types to their HTML equivalent). So this should be doable.

But perhaps I am over thinking this.
Usually we will not need the ability for a user to create paragraphs-in-paragraphs. The paragraphs they create mostly stay on 1 level. But depending on the content-type and the way the site was built, the header for a paragraph should always be an h2, h3 or h4.

Is it possible to set-up a WYSIWYG-editor in Drupal to only allow show a certain header button for a specific content-type? For example the Body of a "Basic page" only allows the H3, but the body of a "News Article" only allows H4?
Or is that something that I would need to implement, if possible?

caschbre’s picture

caschbre commented

I don't think you can configure the wysiwyg editor to that degree out of the box. You could probably write a plugin to the wysiwyg module (and whichever library) that can give you more granular control.

-
@foggyperspectiv | foggyperspective.com (blog)

dennisluitwieler’s picture

dennisluitwieler commented

Thanks for the tip, I did not know it could be possible to customize an existing module to such a detailed level.

sam.spinoy@gmail.com’s picture

sam.spinoy@gmail.com commented

Field collection will do what you want, but like the previous comment stated, it is quite heavy. Also, Field Collections have poor multilingual support. Another thing that comes to mind is the usability. I think it would be easier for a user to just type everything in one big body field rather than having to click "add another paragraph" each time.

So, what I would suggest is to use just one body field, which you could then alter before saving. Implement hook_node_save, grab the body field and identify the header tags through regular expressions or something, and wrap the tags around them. This solution would be harder to implement, but IMHO it´d be easier for the user and give better performance.

dennisluitwieler’s picture

dennisluitwieler commented

Indeed the usability suffers if we use separate entities for paragraphs and so does the page-rendering speed (we have similar issues with our current CMS).

The 1-body approach might indeed be something to reconsider looking at the header tags.
I think most WYSIWYG editors will handle the strong and em tags properly, but we still have to figure out something handy for tables, and (un)ordered lists.