Problem/Motivation

The default text format, Filtered HTML, does not allow content creators to use heading tags (h1 - h6), which is an important web content accessibility concept and is mentioned in WCAG 2.0.

Proposed resolution

Add headings h4-h6 <h4> <h5> <h6> as allowed tags to the default filtered html text format.
This is the proposed resolution in the current patch by mgifford in #58

Issues mentioned in #15 and #51 shouldn't affect this proposed resolution as the current ordering of text formats in D8 has Filtered HTML first.

Remaining tasks

  1. Re-roll #6 against D8.
  2. Append the heading tags to the end, instead of injecting them in between. Even though usable, they are most likely of least interest for users scanning the filter tips for allowed HTML tags.
  3. Update tests accordingly — some tests will likely break due to this change, especially thinking of filter security tests. (Tests not needed per sun's comment at http://drupal.org/node/514008#comment-6738446.)
  4. Open separate issue regarding theming and CSS for comments as suggested by sun in #52.
  5. Open separate issue regarding comment.tpl.php to allow for higher/larger headings than H4 as suggested by sun in http://drupal.org/node/514008#comment-6737668.

User interface changes

The additional heading tags will be listed for users on filter (text format) tips.

API changes

N/A

Original report by Everett Zufelt

The default text format for Drupal 7, Filtered HTML, does not allow content creators to use heading tags (h1 - h6). ATAG 2.0 Principle B.2.3 states: "Accessibility solutions must be promoted and integrated"

The proper use of headings is an important web content accessibility concept and is mentioned in WCAG 2.0.

Recommendation:

That headings h2-h6 be made available by default in the Filtered HTML text format.

See Also

ATAG 2.0
http://www.w3.org/TR/ATAG20/#def-Accessible-Content-Support-Features

G141: Organizing a page using headings | Techniques for WCAG 2.0
http://www.w3.org/TR/WCAG20-TECHS/G141.html

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mgifford’s picture

+1

Filtering out H1's is good as is ensuring that H2-H6 is as available & easy as possible.

veeliam’s picture

The problem I see is that an author may not be aware of the pre-existing hierarchy of headings when entering content.

It'd be magic perhaps to expect the authoring tool to modify the author entered content by parsing the authors intended heading structure, comparing it to its place in the DOM, and then modifying the heading structure to fit appropriately in that hierarchy.

I say this because the content can be placed anywhere on the site with pre-existing and contradicting heading hierarchy. Does that make sense?

Everett Zufelt’s picture

@veeliam, Some good observations. I definitely agree that it would be some sort of magic to have the module automatically determine heading levels based on the contents position within the page, and likely not even desirable. There is definitely a challenge when using different themes of the content creator not knowing which headings are already in use.

Nevertheless, I believe that a solution that allows for headings to be created, even with some reservations, is better than one in which headings cannot be created at all.

veeliam’s picture

I agree, headings ought to be allowed. Cheers!

mgifford’s picture

I still think that one could develop something simple here to discourage folks from using H1 tags. Could simply be a warning that pops up to alert folks that their heading tags are likely going to cause problems with screen readers.

the filter.module could be extended to add a new input that allows admins to enable or disable the warming. Could also possibly auto-renumber the headings by recursively going through H5-H1 dropping headings down one if the body contains an H1 tag. One would need to set the base hierarchy for the main body of the document. The default would probably be H2, but could be set to H1-H6.

Alternatively maybe this should just rolled into an accessibility module - http://drupal.org/project/accessible

Everett Zufelt’s picture

Status: Active » Needs review
FileSize
837 bytes

This patch modifies modules/filter/filter.module : filter_filter_info() to add h2 - h6 elements as allowed tags for the filtered html filter.

mgifford’s picture

Looks good. Wonder if this order makes more sense though:

 '<h2> <h3> <h4> <h5> <h6> <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>'

Just think that in terms of order of importance this ordering makes more sense.

Filtered html doesn't work well with most wysiyg editors. Works better with comments. However, not sure if we want allow putting in comments with headings.

Cliff’s picture

Status: Needs review » Active

I'm baffled as to why the default text format would forbid the use of the most basic tools for making information accessible. But Mike is right in pointing out that people should not be allowed to enter an H1 that isn't being used as the title of the page.

I need to learn a lot more about the way content is managed in Drupal before I get into whether a relative filter would be better than an absolute limit. (By "relative filter," I mean a script or widget that would take content, adjust its highest heading level to, say, 3, and then make the corresponding adjustment to the level of all other headings in that content. By "absolute limit," I mean a script or widget that would force content providers to reformat their headings if the highest heading level was too high.)

But would it be impossible to designate headings in added content as "hmax," "hmax+1," "hmax+2," and so on and then, in the generated code, have "max" set to 1 if in the current context the highest heading in the content being used should become an h1, 2 if in the current context the highest heading should become an h2, and so on?

Cliff’s picture

Wrote #8 while Everett and you were posting #6 and #7, so I didn't see them.

If filtered html is for comments only, then I would go even further: Filter out H2 and H3 as well. As I mentioned in http://groups.drupal.org/node/26247#comment-90249, the heading for a comment is almost always an H3. So why should anything entered in the comment ever be higher than an H4?

Everett Zufelt’s picture

Status: Active » Needs review

Setting back to NR

bowersox’s picture

+1 for this feature and for the patch in #8. Use of headings should definitely be allowed by default to promote accessibility. Is there any reason this patch isn't ready to go?

@Cliff: Regarding some of the ideas for a 'relative filter' and 'absolute limit', those are neat ideas but I think we need to save them for a future patch. I don't think we have the mechanics currently to have our filter work differently for comments versus node body or to recalculate heading levels on submission. And of course this will all change with HTML 5 headings.

mgifford’s picture

I believe that the argument was that adding headings can actually cause more problems than they solve if they aren't nested properly.

If a comment block is under H4 then they should only be given the option of using H5 & H6.

You might want to nest other field elements under an H3 heading.

If we generically let people choose between H2-H6 then they can break logic really easily.

There's no way for the input filter to know what heading level it is sitting in.

Ultimately it's down to whether or not you trust the user to know what they are doing.

sun’s picture

I don't think we want to do this.

The Filtered HTML text format is mainly used for comments by anonymous users in D7. Because, for all other users, the new default text format handling will automatically assign a more permissive text format by default. Hence, when you create a node, you'll most likely create it with Full HTML or a custom text format, which allows you to use all or more tags.

mgifford’s picture

Status: Needs review » Closed (won't fix)

Since that's the case I'm moving this status to won't fix. I can't see allowing headings to be added by anonymous users to be a good thing.

People should feel free to bring it back to active though if there's either a different use case or a better workaround for the problems stated abovel

David_Rothstein’s picture

Title: Heading tags not available in default Filtered HTML text format: required for compliance with ATAG 2.0 » Make Full HTML the default text format for administrators in the standard install profile (helps compliance with ATAG 2.0)
Status: Closed (won't fix) » Active

@sun's explanation above is 90% correct. However, by default, we currently do not configure a new Drupal installation that way. Full HMTL is not the preferred text format (by weight); thus, administrators do not create content with it unless they specifically select it.

We could very easily adjust the weights in the standard install profile so that Full HTML is the highest, and then any user with permission to use it would automatically have that be their default. There are pros and cons to that, I think. Seems like one of the pros is the accessibility issue mentioned here. One of the cons is that if you want to use Drupal to make a wiki, that won't work well because content created by administrators would (by default) not be editable by less-privileged users. I don't know to what extent the standard install profile is really conducive to a wiki site anyway, though :)

I don't know where I stand on this, but it is at least a viable possibility, so I'm reopening this issue based on that idea.

Everett Zufelt’s picture

Would it be viable to have an additional input format, filtered html with headings?

David_Rothstein’s picture

We could, but I'm not sure it's worth it over just using Full HTML.

It would be useful for an "editor" role who creates lots of content (but isn't trusted not to attack the site and therefore shouldn't get Full HTML), but I'm not sure that's common enough to justify adding it as one of the default formats in the install profile.

Everett Zufelt’s picture

I am definitely open to full html being the default. One of the first things I do on install is add h2 h3 h4 to the filtered html format.

sun’s picture

Version: 7.x-dev » 8.x-dev

That requires to rewrite countless of tests, and I'm not sure why users can't simply select the Full HTML format when creating new articles or page content. Or re-configure the defaults.

mgifford’s picture

Version: 8.x-dev » 7.x-dev
Status: Active » Needs review
FileSize
73.22 KB
76.13 KB
852 bytes

We may well have to bump this to D8, but because I want to run the patch past the bot, I'm switching this back to D7. The goal I see is for Drupal to choose accessible options by default and make it harder for people to make less accessible websites.

People should assume the defaults are as accessible as possible just like they assume that the defaults are as secure as possible. It should be an effort to re-configure the defaults for an option that doesn't inspire users to use the best practice.

I closed this issue in Nov of last year in issue #14 based on the best information we had at the time. Switching the order of the filters may be a simpler solution that we might think. Certainly with my local testing this patch seems to be getting passed them with no problem.

sun’s picture

well, the consequence of this patch is that user A having access to Full HTML will create a content, not caring for the text format, and user B then complains that she's not able to edit it.

Status: Needs review » Needs work

The last submitted patch, 514008-2.patch, failed testing.

Everett Zufelt’s picture

Status: Needs work » Needs review

Agreed with @Sun that we don't want to have full html as default for reasons given.

Looking at the pros and cons from an accessibility perspectitve, the pro of having headings (even if improperly nested) outweighs the con of not having headings.

There is no good solution available to have relative headings in d7, so headings will always be broken. Example is a node with 3 h2 headings. When viewed on its own in Bartik it is proper, as node title is h1. When viewed on /node it is improper, since node title is h2.

I am in support of adding h2 - h6 (perhaps only h2bb - h4 for simplicity) to filtered html.

mgifford’s picture

Sorry, but why does user B not have the ability to edit user A's HTML? As it is right now only another administrator would be able to edit it, this is true, but I'm not sure who else should be able to edit an administrator's work.. If there is a text only content type that you want all users to access, wouldn't it make sense to restrict what filters apply for that context?

sun’s picture

Version: 7.x-dev » 8.x-dev

This change has too many unintended consequences -- regardless of what is done. See #13 for why we don't want to add headings to Filtered HTML.

This overall situation might be improved for D8, if we somehow manage to restrict available formats per entity or field, or if we entirely kill text formats and only keep filters. Both requires substantial changes to the overall system.

Let's focus on the real pressing D7 bugs, please. Thanks.

Everett Zufelt’s picture

Version: 8.x-dev » 7.x-dev

@Sun

"The Filtered HTML text format is mainly used for comments by anonymous users in D7. Because, for all other users, the new default text format handling will
automatically assign a more permissive text format by default. Hence, when you create a node, you'll most likely create it with Full HTML or a custom text
format, which allows you to use all or more tags."

Documentation please.

sun’s picture

Everett Zufelt’s picture

So the question is whether on average accessibility is improved, or worsened by placing headings in to the average content creator's hands.

Being in the camp that would generally tend not to trust users to make good decisions about markup I'll agree with @sun here and say that we should wait for D8 to try to plan early for a good implementation of headings in content.

mgifford’s picture

Can this be brought into D7 using the Accessible Helper Module?

Liam Morland’s picture

Everett Zufelt’s picture

Title: Make Full HTML the default text format for administrators in the standard install profile (helps compliance with ATAG 2.0) » Allow <h2> ... <h?> in filtered html text format
Status: Needs review » Active

I'm still not sure if we should do this, but the best way to solve this problem at the moment seems to be to add <h2> ... <h?> to the filtered html text format. This is what I do whenever I setup a site.

I'm not sure that we need to go as far as h6, and don't know how headings are styled in core themes.

mgifford’s picture

Status: Active » Needs review

#6: filterd_html_headings_1.patch queued for re-testing.

drupal_was_my_past’s picture

Subscribe

xjm’s picture

Hmm, I really don't think #20 is a good solution. What Everett suggests in #31 seems like a better approach to me, but it's also true that adding header tags gives people the ability to use them for font size, put them in the wrong order, and possibly make page layouts screwy.

I wonder if we should have different default input formats for anonymous and authenticated users?

droplet’s picture

sometimes I use

H2 tag to emphasize my word

in comment section when the site don't give me permission to use font-size. I know I'm wrong but I still do it.

We have to think about it. Should we get all things into Drupal ?

or maybe add more default text format ??

- filtered html
(legacy filter)
- full html
(legacy filter)
- accessibility filters
(H tag,....etc)
- comment filters
(strong, em, code, a, u)

mgifford’s picture

@droplet just noting that your use of an H2 is for emphasis. And absolutely you should be using heading tags to emphasize things.

However, why not an H1 or an H3? You know it would be bad to use the H1 in the body of your text and are used to using H2's. But seriously, the scale of the emphasis is controlled by CSS right? I suspect that you aren't also in that same document using a full hierarchy that gets down to an H6, right?

So we just have to modify the sizes in the CSS so that the emphasis in the H3 is the same as it was in the H2 in core. That way all we'd be changing is habits (and D8 will be a good time to do that for us all).

I don't think adding more filter options is a good idea.

mgifford’s picture

FileSize
715 bytes

Just updating to the latest Git format.

Status: Needs review » Needs work

The last submitted patch, 514008-3.patch, failed testing.

mgifford’s picture

Title: Allow <h2> ... <h?> in filtered html text format » Allow <h2> ... <h?> in default filtered html text format
Status: Needs work » Postponed

Postponed until we know how http://drupal.org/project/spark deals with the html text format.

David_Rothstein’s picture

Status: Postponed » Needs work

I'm not sure if that was a mistake... but this is a core issue, nothing to do with Spark. Reopening for now.

webchick’s picture

Yeah, I completely agree. No reason to hold up any core issue on Spark. :)

sun’s picture

Issue tags: +Needs design review

My main concern was that the filtered_html format is mainly used for comments on most sites. Headings in comments were almost always inappropriate and also tended to break the structure of headings in the HTML markup.

HTML5 changes this entirely though, and H2-H6 headings can be reasonably supported in comments and other content.

Thus, the patch in #6 is possible to do now.

Tasks:

  1. Re-roll #6 against D8.
  2. Append the heading tags to the end, instead of injecting them in between. Even though usable, they are most likely of least interest for users scanning the filter tips for allowed HTML tags.
  3. Update tests accordingly — some tests will likely break due to this change, especially thinking of filter security tests.
Bojhan’s picture

Not sure what to review in terms of design, I think this makes a lot of sense for content creators. With WYSIWYG going into core, we need to consider how much of that we expose in comment forms.

mgifford’s picture

Status: Needs work » Needs review
FileSize
760 bytes

Just a re-roll for the bot.

Status: Needs review » Needs work

The last submitted patch, 514008-44.patch, failed testing.

xjm’s picture

So the current title and summary do not at all describe the current patch, which seems to be swapping the ordering of the full and filtered HTML filters. Could we clarify?

mgifford’s picture

Status: Needs work » Needs review
Issue tags: -Needs issue summary update
FileSize
684 bytes

@xjm - I don't think it matters to other Accessibility folks if we either allow h2 h3 h4 to the filtered html format by default or set full html being the default.

That changed here (and the title wasn't updated)
http://drupal.org/node/514008#comment-3496362

Have any sense of which would be more likely to get into Core?

EDIT: Rerolled adding the h2->h6 for the filtered html.

webchick’s picture

We are absolutely not making full HTML the default. The default format is available to anonymous users, and there is no end of pain you can cause a site with access to tags like object, embed, etc.

xjm’s picture

@mgifford, I'm not weighing in on proposed solutions; I'm just asking that the title and summary actually document the options under discussion.

mgifford’s picture

The feedback from @webchick is all I need for this.

The title can stay the same & the patch in #47 is consistent with it.

I didn't mean to remove the "Issue summary initiative" tag.

David_Rothstein’s picture

@webchick's comment actually only applies to Drupal 6 and earlier. For Drupal 7 and higher, this is not the case - anonymous users do not necessarily have access to the administrator's default format.

The problem though is that different default formats for different users can cause issues for sites with wiki-type content (see #15).

So that might be a reason not to do it anyway (if we care about optimizing the standard install profile for that use case); however, there is no security problem doing it either way.

sun’s picture

comment.tpl.php outputs:

  <h3<?php print $title_attributes; ?>><?php print $title; ?></h3>

Thus, if you allow H2 and H3, then the comment content can contain a heading that is structurally higher than the comment's title/heading itself.

As long as comment.tpl.php contains H3, we should only allow for H4, H5, H6.

I will directly amend this and say that there's no apparent reason for why comment.tpl.php uses a H3. The entire comment forms an article, which represents a section of content that forms an independent part of a document or site, and the HTML5 spec defines that articles can and should be nested for the purpose of an article with comments (which is the case in HEAD already). Within an article, the hierarchy of HTML headings is restarts from scratch. So technically, comment.tpl.php could use a H1 for the comment title/subject. But that obviously requires themes to properly account for headings in nested articles; e.g., like this:

article h1 { font-size: 2em; font-weight: bold; }
article article h1 { font-size: inherit; }

Adjusting that is a separate issue though.

xjm’s picture

A magic thing to give you semantic, ordered headers contextually would be amazing, but I'm not sure how that could work since one can always put whatever in the template.

mgifford’s picture

I don't profess to be an expert in HTML5 by any means, but I do believe we can relax a little in terms of order issue. HTML5 seems to be much more flexible:

http://www.netmagazine.com/tutorials/html5-ranked-headings-screen-readers
http://www.456bereastreet.com/archive/201103/html5_sectioning_elements_h...
http://ablognotlimited.com/articles/the-beauty-of-semantic-markup-part-3...
https://developer.mozilla.org/en-US/docs/Sections_and_Outlines_of_an_HTM...
http://coding.smashingmagazine.com/2011/08/16/html5-and-the-document-out...

We can also evaluate some comments with:
http://gsnedders.html5.org/outliner/

The accessibility folks spent quite a lot of time looking at this issue and looking for the magic to provide contextually ordered headers, but I think that's essentially been done by HTML5.

timwood’s picture

Title: Allow <h2> ... <h?> in default filtered html text format » Allow <h2> ... <h6> in default filtered html text format
Issue tags: -Needs issue summary update

My attempt at a revised issue summary.

mgifford’s picture

Good summary Tim. Hopefully we can find some time to re-roll this at the a11y sprint this weekend.

sun’s picture

Status: Needs review » Needs work

I'm happy to do this change for D8, but I still stand by #52 — in order to allow higher/larger headings than H4, comment.tpl.php has to be changed.

I'm not sure whether it is a good idea to mix that change into this issue/patch... but we could try.

mgifford’s picture

Status: Needs work » Needs review
Issue tags: +a11ySprint
FileSize
674 bytes

3 headings is fine for unfiltered text and it doesn't really matter where they start for me.

I haven't added the tests, but I have moved them to the end of the string as requested.

Would this work?

sun’s picture

Title: Allow <h2> ... <h6> in default filtered html text format » Allow HTML headings in default Filtered HTML text format
Status: Needs review » Reviewed & tested by the community

Heh. By definition of #57, the patch in #58 is completely fine with me, and can be RTBC'ed anytime.

That said, since allowing "some" headings in Filtered HTML was the entire and sole purpose of this issue since the beginning, let me go ahead directly.

This is pure default configuration, not functionality, so tests are not needed.

mgifford’s picture

Excellent!

mgifford’s picture

Issue summary: View changes

Attempt at summarizing issue.

timwood’s picture

I updated the summary to reflect recent comments and also tested the patch. Looks good!

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Greetings from the Drupal Accessibility sprint in Toronto! :D

We discussed this issue. One concern we've had in the past of putting hX tags in filtered HTML is a lot of users misunderstand these tags and think they mean "make this text bold" rather than their proper semantic meaning. However, Mike pointed out that as of HTML5, these headings only affect their particular section container, so the risk of people using these improperly is a lot less now. I also inquired as to whether we wanted to include an upgrade path for this, since existing D7 sites moving to D8 would not get these extra tags. However, it was decided that we shouldn't really make assumptions and mess with existing sites, since it might cause unexpected behaviour, such as heading buttons suddenly appearing in WYSIWYG editors that weren't there before, etc.

So.....

Committed and pushed to 8.x! Thanks! :D

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

johnheaven’s picture

Hi All. I know this has been discussed at length a while ago, but I just came across this issue because I posted a similar issue myself a couple of weeks ago.

I created an article with the Basic HTML filter and was only able to use h4-h6 headings. That wasn't a problem for me - I just assumed that was intentional - so I used the h4 for my headings. Unfortunately, the h4 styling is indistinguishable from regular text.

I assumed that was a bug, especially as the Wysiwyg shows h4s as bold text. Here's the issue that I logged, with the full description: H4 element not distinguishable from rest of text.

If it's confusing for me, I'm sure it would be confusing for quite a lot of other people.

johnheaven’s picture

Issue summary: View changes

Revised summary for recent comments and changes.