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
Re-roll #6 against D8.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.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.)- Open separate issue regarding theming and CSS for comments as suggested by sun in #52.
- 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
Comment | File | Size | Author |
---|---|---|---|
#58 | filterd_html_headings_58.patch | 674 bytes | mgifford |
#47 | filterd_html_headings_47.patch | 684 bytes | mgifford |
#44 | 514008-44.patch | 760 bytes | mgifford |
#37 | 514008-3.patch | 715 bytes | mgifford |
#20 | 514008-2.patch | 852 bytes | mgifford |
Comments
Comment #1
mgifford+1
Filtering out H1's is good as is ensuring that H2-H6 is as available & easy as possible.
Comment #2
veeliam CreditAttribution: veeliam commentedThe 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?
Comment #3
Everett Zufelt CreditAttribution: Everett Zufelt commented@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.
Comment #4
veeliam CreditAttribution: veeliam commentedI agree, headings ought to be allowed. Cheers!
Comment #5
mgiffordI 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
Comment #6
Everett Zufelt CreditAttribution: Everett Zufelt commentedThis patch modifies modules/filter/filter.module : filter_filter_info() to add h2 - h6 elements as allowed tags for the filtered html filter.
Comment #7
mgiffordLooks good. Wonder if this order makes more sense though:
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.
Comment #8
Cliff CreditAttribution: Cliff commentedI'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?
Comment #9
Cliff CreditAttribution: Cliff commentedWrote #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?
Comment #10
Everett Zufelt CreditAttribution: Everett Zufelt commentedSetting back to NR
Comment #11
bowersox CreditAttribution: bowersox commented+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.
Comment #12
mgiffordI 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.
Comment #13
sunI 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.
Comment #14
mgiffordSince 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
Comment #15
David_Rothstein CreditAttribution: David_Rothstein commented@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.
Comment #16
Everett Zufelt CreditAttribution: Everett Zufelt commentedWould it be viable to have an additional input format, filtered html with headings?
Comment #17
David_Rothstein CreditAttribution: David_Rothstein commentedWe 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.
Comment #18
Everett Zufelt CreditAttribution: Everett Zufelt commentedI 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.
Comment #19
sunThat 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.
Comment #20
mgiffordWe 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.
Comment #21
sunwell, 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.
Comment #23
Everett Zufelt CreditAttribution: Everett Zufelt commentedAgreed 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.
Comment #24
mgiffordSorry, 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?
Comment #25
sunThis 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.
Comment #26
Everett Zufelt CreditAttribution: Everett Zufelt commented@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.
Comment #27
sunMainly:
#717176: Clarify relationship between order and selected status of text formats
But also:
#256552: Allow more html tags by default.
#275811: Warn about potentially insecure filter configurations
Comment #28
Everett Zufelt CreditAttribution: Everett Zufelt commentedSo 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.
Comment #29
mgiffordCan this be brought into D7 using the Accessible Helper Module?
Comment #30
Liam MorlandComment #31
Everett Zufelt CreditAttribution: Everett Zufelt commentedI'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.
Comment #32
mgifford#6: filterd_html_headings_1.patch queued for re-testing.
Comment #33
drupal_was_my_past CreditAttribution: drupal_was_my_past commentedSubscribe
Comment #34
xjmHmm, 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?
Comment #35
droplet CreditAttribution: droplet commentedsometimes 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)
Comment #36
mgifford@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.
Comment #37
mgiffordJust updating to the latest Git format.
Comment #39
mgiffordPostponed until we know how http://drupal.org/project/spark deals with the html text format.
Comment #40
David_Rothstein CreditAttribution: David_Rothstein commentedI'm not sure if that was a mistake... but this is a core issue, nothing to do with Spark. Reopening for now.
Comment #41
webchickYeah, I completely agree. No reason to hold up any core issue on Spark. :)
Comment #42
sunMy 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:
Comment #43
Bojhan CreditAttribution: Bojhan commentedNot 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.
Comment #44
mgiffordJust a re-roll for the bot.
Comment #46
xjmSo 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?
Comment #47
mgifford@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.
Comment #48
webchickWe 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.
Comment #49
xjm@mgifford, I'm not weighing in on proposed solutions; I'm just asking that the title and summary actually document the options under discussion.
Comment #50
mgiffordThe 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.
Comment #51
David_Rothstein CreditAttribution: David_Rothstein commented@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.
Comment #52
suncomment.tpl.php outputs:
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:
Adjusting that is a separate issue though.
Comment #53
xjmA 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.
Comment #54
mgiffordI 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.
Comment #55
timwoodMy attempt at a revised issue summary.
Comment #56
mgiffordGood summary Tim. Hopefully we can find some time to re-roll this at the a11y sprint this weekend.
Comment #57
sunI'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.
Comment #58
mgifford3 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?
Comment #59
sunHeh. 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.
Comment #60
mgiffordExcellent!
Comment #60.0
mgiffordAttempt at summarizing issue.
Comment #61
timwoodI updated the summary to reflect recent comments and also tested the patch. Looks good!
Comment #62
webchickGreetings 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
Comment #64
johnheaven CreditAttribution: johnheaven commentedHi 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.
Comment #64.0
johnheaven CreditAttribution: johnheaven commentedRevised summary for recent comments and changes.