Posted by Everett Zufelt on July 8, 2009 at 8:26pm
12 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | filter.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | accessibility, atag, wcag |
Issue Summary
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
Comments
#1
+1
Filtering out H1's is good as is ensuring that H2-H6 is as available & easy as possible.
#2
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?
#3
@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.
#4
I agree, headings ought to be allowed. Cheers!
#5
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
#6
This patch modifies modules/filter/filter.module : filter_filter_info() to add h2 - h6 elements as allowed tags for the filtered html filter.
#7
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.
#8
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?
#9
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?
#10
Setting back to NR
#11
+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.
#12
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.
#13
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.
#14
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
#15
@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.
#16
Would it be viable to have an additional input format, filtered html with headings?
#17
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.
#18
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.
#19
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.
#20
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.
#21
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.
#22
The last submitted patch, 514008-2.patch, failed testing.
#23
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.
#24
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?
#25
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.
#26
@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.
#27
Mainly:
#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
#28
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.
#29
Can this be brought into D7 using the Accessible Helper Module?
#30
#31
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.
#32
#6: filterd_html_headings_1.patch queued for re-testing.
#33
Subscribe
#34
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?
#35
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)
#36
@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.
#37
Just updating to the latest Git format.
#38
The last submitted patch, 514008-3.patch, failed testing.