ChangeProposal/meta name=generator does not make missing alt conforming
From HTML WG Wiki
Change Proposal: The <meta name=generator> string should not make missing alt conforming
The following Change Proposal relates to: the HTML WG decision on alt validity requirements.
Editor: Steve Faulkner (firstname.lastname@example.org)
updated: January 25th 2012
This Change Proposal provides new evidence showing how authors can (and do) directly hand-edit content in commonly used Content Management Systems (CMS). author editing can bring content into conformance with WCAG2, or take it out of conformance with WCAG2 regardless of whether (or not) a CMS is being used. This CP provides new evidence that there is no correlation between CMS content management and the ability to conform to WCAG2 requirements. there is, therefore, no correlative justification for a blanket exemption from the WCAG2 requirement for alternative text markup on images for CMS managed content. In particular this CP shows that CMS does not prevent WCAG2 conformance in CMS.
current usage of meta name=generator (New)
It has previously been asserted that:
"we need a way for validators and authoring tools to coordinate so that validators will not criticise conforming authoring tools when a problem (in this case missing alternative text) is the user's fault and not the author tool's. The simplest solution here is to reuse the existing document-wide flag that indicates that a document was created by an authoring tool" source: original counter proposal
Current usage of name=generator does not match the notion that documents using this meta element attribute are produced using wysiwyg editors. It is widely used by content management systems such as:
- Wordpress = 14.6% of web sites.
- Joomla! = 2.7% of web sites.
- Drupal = 1.6% of web sites.
- vBulletin =1.4% of web sites
- Blogger = 0.8% of web sites
Example meta tags of used by the above CMS's:
<meta name="generator" content="WordPress 3.1"/> <meta content="Joomla! 1.5 - Open Source Content Management" name="generator"> <meta content="Drupal 7 (http://drupal.org)" name="Generator"> <meta name="generator" content="vBulletin 4.1.4"> <meta name="generator" content="Blogger" />
Each of these content management systems can be used in conjunction with a range of HTML editor applications:
The majority of which include a feature to allow authors to edit the source code directly, i.e. include a non WYSIWIG authoring component.
Majority of content not exclusively WYSIWYG (New)
It has previously been asserted that:
"The simplest solution here is to reuse the existing document-wide flag that indicates that a document was created by an authoring tool" source: original counter proposal
Re-use of the exisiting document wide flag ONLY makes sense if the content is made solely using a WYSIWYG editor:
The WYSIWYG edited content is only a subset of the content in any document produced using a CMS. CMS templates can be customized using any type of coding method, this usually involves editing in a non-WYSIWYG environment due to the source documents using a non-HTML scripting language. Examples of editors used to code vbulletin templates. Wordpress allows direct modification of template files from within the admin section and also lists editors to use.
All of the above content management systems allow 3rd party addons or widgets to be included such as calendars, google+1 buttons, flickr feeds etc. It is posited that vast majority of these addons are not developed using WYSIWIG editors.
WYSYWIG applications (new)
No evidence has been produced that backs up the follwing claim:
"Unfortunately, despite what the specification says, users will consider an authoring tool non-conforming (buggy) if the documents it outputs are not flagged as conforming by validators." source: original counter proposal
None (to my knowledge) of the popular WYSIWYG editors available today are soley WYSIWYG, all allow the user to edit code directly and all allow the author to save the resulting HTML as a file regardless of the conformance errors (relative to the DOCTYPE) contained within the file. For example I can edit a document in Adobe Dreamweaver with a HTML5 doctype and include a cellpadding attribute on a table element, even though it is obselete. I am not forced to remove before being able to save the file.
I strongly suggest this is a feature not a bug. ONLY allowing authors to save a file conforming the DOCTYPE used would be seen as a bug. For example the default in editor Wordpress does not allow me to add a role attribute to an element in the code view, even though I am using a HTML5 DOCTYPE. This is a bug in the editor. What I can do is disable the wpautop function so that WordPress makes no attempt to correct my markup.
It does however allow me to add <table cellpadding="5"> or <table cellpadding="k"> neither of which are conforming in HTML5.
Assumed agreement and need (New)
The tacking on of the conformance exception to name=generator alters its effect quite dramatically, previously the use of name=generator has had no effect upon anything, now it hides conformance errors. name=generator is present on approx 27% of all web pages: Looking at the results from the Opera mama survey of web pages, the Total analyzed URLs was 3,509,180. The total number of pages containing a meta element with name=generator was 942,051. So that appears to equate to missing alt will not be flagged as an error on 27% of web pages. If historical trends are anything to go by,it is unlikely that this will change as content managment and authoring tool developers switch or allow the option to produce documents using the HTML5 doctype. There has been no evidence presented by proponents of the change to indicate that authoring tool implementors or end users(authors) have asked or agree with this exception been tacked on to a formerly neutral attribute value that merely flagged the use of a particular tool.
There is also no way for individual authors using CMS systems to opt out of the hiding of conformance errors, unless they have permissions to change the CMS code (highly unlikely) and it it is highly unlikely that users of CMS's and authoring tools that include name=generator in the code by default will be aware of this tacked on conformance modification in the first place. This will lead to authors assumimg their content is conforming and that they have produced an accessible document, when it may not be the case.
Requirement for use of name=generator does not match reality
As described above, the current requirement that name=generator
must not be used on hand-authored pages
does not in any sense match its current or historical usage, the very concept of 'hand authored pages' is meaningless as all pages are produced using some form of document authoring tool and there is no way for a checker tool to know whether the production of all, part or none of a published document did not involve the direct editing of code.
Wordpress Joomla Drupal
From the section 220.127.116.11.13 Guidance for conformance checkers
remove the following:
The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string "generator". (This case does not represent a case where the document is conforming, only that the generator could not determine appropriate alternative text — validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.)
From the section 4.2.5 The meta element
remove the following:
This value must not be used on hand-authored pages.
- authors can more safely assume that when they use a conformace checker it will check the conformance of the document not some abitrary subset of requirements.
- the use of meta name=generator will not change in a way that is contrary to its current usage and effects.
- authors will be made aware that they have not provided a text alternative giving them the opportunity to fix their error and produce a conformaing document.
Conformance Classes Changes