As part of my work at Bocoup, I recently started working with browser implementers to improve the state of fieldset, the 21 year old feature in HTML, that provides form accessibility benefits to assistive technologies like screen readers. It suffers from a number of interoperability bugs that make it difficult for web developers to use.
Here is an example form grouped with a <legend> caption in a <fieldset> element:
Based on a query of the HTTP Archive data set, containing the raw content of the top 1.3 million web pages, we find the relative usage of each HTML element. The fieldset element is used on 8.41% of the web pages, which is higher than other popular features, such as the video and canvas elements; however, the legend element is used on 2.46% of web pages, which is not ideal for assistive technologies. Meanwhile, the form element appears on 70.55% of pages, and we believe that if interoperability bugs were fixed, correct and semantic fieldset and legend use would increase, and have a positive impact on form accessibility for the web.
Fieldset standards history
In January 1997, HTML 3.2 introduces forms and some form controls, but does not include the fieldset or legend elements.
The FIELDSET element allows form designers to group thematically
related controls together. Grouping controls makes it easier for users
to understand their purpose while simultaneously facilitating tabbing
navigation for visual user agents and speech navigation for
speech-oriented user agents. The proper use of this element makes
documents more accessible to people with disabilities.
The LEGEND element allows designers to assign a caption to a FIELDSET.
The legend improves accessibility when the FIELDSET is rendered
non-visually. When rendered visually, setting the align attribute on
the LEGEND element aligns it with respect to the FIELDSET.
In December 1999, HTML 4.01 is published as a W3C Recommendation, without changing the definitions of the fieldset and legend elements.
In August 2018, I proposed a number of changes to the standard to better define how it should work, and resolve ambiguity between browser implementer interpretations.
Current state
As part of our work at Bocoup to improve the interoperability of the fieldset and legend child element, we talked to web developers and browser implementers, proposed changes to the standard, and wrote a lot of tests. At the time of this writing, 26 issues have been reported on the HTML specification for the fieldset element, and the tests that we wrote show a clear lack of interoperability among browser engines.
Of the 26 issues filed against the specification, 17 are about rendering interoperability. These rendering issues affect use cases such as making a fieldset scrollable, which currently result in broken scroll-rendering in some browsers. These issues also affect consistent legend rendering which is causing web developers avoid using the fieldset element altogether. Since the fieldset element is intended to help people who use assistive technologies to navigate forms, the current situation is less than ideal.
HTML spec rendering issues
In April of this year, Mozilla developers filed a meta-issue on the HTML specification “Need to spec fieldset layout” to address the ambiguities which have been leading to interoperability issues between browser implementations. During the past few weeks of work on fieldset, we made initial proposed changes to the rendering section of the HTML standard to address these 17 issues. At the time of this writing, these changes are under review.
Proposal to extend -webkit-appearance
Web developers also struggle with changing the default behaviors of fieldset and legend and seek ways to turn off the “magic” to have the elements render as normal elements. To address this, we created a proposal to extend the -webkit-appearance CSS property with a new value called fieldset and a new property called legend that are together capable giving grouped rendering behavior to regular elements, as well as resetting fieldset/legend elements to behave like normal elements.
The general purpose proposed specification for an "unprefixed" CSS ‘appearance’ property, has been blocked by Mozilla's statement that it is not web-compatible as currently defined, meaning that implementing appearance would break the existing behavior of websites that are currently using CSS appearance in a different way.
We asked the W3C CSS working group for feedback on the above approach, and they had some reservations and will develop an alternative proposal. When there is consensus for how it should work, we will update the specification and tests accordingly.
We had also considered defining new display values for fieldset and legend, but care needs to be taken to preserve web compatibility. There are thousands of pages in HTTP Archive that set ‘display’ to something on fieldset or legend, but browsers typically behave as display: block was set. For example, specifying display: inline on the legend needs to render the same as it does by default.
In parallel, we authored an initial specification for the ‘-webkit-appearance’ property in Mike Taylor's WHATWG Compatibility standard (which reverse engineers web platform wonk into status quo specifications), along with accompanying tests. More work needs to be done for the ‘-webkit-appearance’ (or unprefixed ‘appearance’) to define what the values mean and to reach interoperability on the supported values.
Accessibility Issues
We have started looking into testing accessibility explicitly, to ensure that the elements remain accessible even when they are styled in particular ways.
This work has uncovered ambiguities in the specification, which we have submitted a proposal to address. We have also identified interoperability issues in the accessiblity mapping in implementations, which we havereported.
Implementation fixes
Meta bugs have been reported for each browser engine (Gecko, Chromium, WebKit, EdgeHTML), which depend on more specific bugs.
As of September 18 2018, the following issues have been fixed in Gecko:
The WebKit and Edge teams are aware of bugs, and we will follow up with them to track progress.
Conclusion
The fieldset and legend elements are useful to group related form controls, in particular to aid people who use assistive technologies. They are currently not interoperable and are difficult for web developers to style. With our work and proposal, we aim to resolve the problems so that they can be used without restrictions and behave the same in all browser engines, which will benefit browser implementers, web developers, and end users.
I see more and more people switch over to HTML5 these days, and to help you make sure you did things correctly, there are some tools at your disposal that might be good to know about.
To make sure you didn't misspell any tag or nest elements in a way that is not allowed, or find similar mistakes in your markup, you can use Validator.nu.
Alt text for images
The above-mentioned validator has a feature to help you quality-check your alternative text for your img elements. Check the Show Image Report checkbox.
You can also disable images in your browser or try to use a text-only browser — the information that the images convey should still be available (but in text form). Sometimes an image doesn't convey any further information than what the surrounding text already says, and in such cases you should use the empty value: alt="".
For further advice and examples on how to use the alt attribute, the HTML 5 spec has lots of information on the topic. If you're not going to read it all, just read the section called General guidelines.
Document outline
The document outline is the structure of sections in the document, built from the h1-h6 elements as well as the new sectioning elements (section, article, aside, nav). The document outline is more commonly known as the Table of Contents.
To make sure that you have used the new sectioning elements correctly, you can check that the resulting outline makes sense with the HTML5 Outliner.
If you see "Untitled Section" and didn't expect them, chances are that you should have used div instead of section.
If you have a subtitle of a heading that shouldn't be part of the document outline, you should use the hgroup element:
<hgroup>
<h1>The World Wide Web Consortium</h1>
<h2>Leading the Web to Its Full Potential...</h2>
</hgroup>
In this example, only the h1 will show up in the document outline.
Table inspector
(This only applies to table elements used for tabular data — not for layout.)
HTML tables have two types of cells: header cells (th elements) and data cells (td elements). These cells are associated together in the table: a data cell in the middle of the table can have associated header cells, typically in the first row and/or the first column of the table. To a user who can see, this association seems obvious, but users who cannot see need some help from the computer to understand which cells are associated with which.
You should mark up your header cells with the th element and check that your cells get associated as you intended using the Table Inspector. If it isn't as you intended, you can consider simplifying or rearranging your table, or you can override the default association using scope or headers attributes.
Other tools?
If you know about other tools for helping with quality assurance of HTML5, or if you have made your own, please share!
We have previouslytalked about how to get Internet Explorer to play ball when using the new HTML5 elements, but today I'm going to talk about Firefox 2.
Firefox 2 (or any other Gecko-based browser with a Gecko version pre 1.9b5) has a parsing bug where it will close an unknown element when it sees the start tag of a "block" element like p, h1, div, and so forth. So if you have:
So if you style the new elements with CSS it will probably look completely broken in Firefox 2.
If you care about Firefox 2 then there are some ways to fix this:
Go back to using div elements
Use content type negotiation between text/html and application/xhtml+xml
Fix up the DOM with scripting
(1) is probably wise if your content structure changes between pages or over time. (2) also works but means that users will be exposed to the Yellow Screen of Death should a markup error slip through your system. Otherwise (3) can be worth to consider.
Fixing up Firefox 2's DOM is actually pretty simple if you have a consistent structure. Using the same markup as above it could look something like this:
<body>
<header>
<h1>Test</h1>
</header>
<article>
<p>...</p>
...
</article>
<nav>
<ul>...</ul>
</nav>
<footer>
<p>...</p>
</footer>
<!--[if !IE]>--><script>
// dom fixup for gecko pre 1.9b5
var n = document.getElementsByTagName('header')[0];
if (n.childNodes.length <= 1) { // the element was closed early
var tags = ['ARTICLE', 'NAV', 'FOOTER', 'SCRIPT'];
for (var i = 0; i < tags.length; ++i) {
while (n.nextSibling && n.nextSibling.nodeName != tags[i]) {
n.appendChild(n.nextSibling);
}
n = n.nextSibling;
}
}
</script><!--<![endif]-->
</body>
You might think that this script would work for IE, too, when not using the createElement hack, but apparently IE throws an exception when trying to append a child to an unknown element. So you still have to use the createElement hack for IE.
If you want to move the script to head and run it on load and you don't have anything after the footer then you would replace 'SCRIPT' in the tags array with undefined to make it work.
(If you want to do content type negotiation and want to just serve XHTML to Gecko-based browsers with this bug then you should look for the substrings "Gecko/" and "rv:1.x" where x is less than 9, or "rv:1.9pre" or "rv:1.9a" or "rv:1.9bx" where x is less than 5.)
The previous post discussed how to enable styling of the new HTML5 elements in IE by using a simple script. However, if the user has scripting disabled, the layout would probably fall apart badly.
So that means if you care about IE users with scripting disabled, you can't use the new elements, right?
Not necessarily.
There are some tricks to work around the broken DOM and limited styling in IE:
Know what the DOM looks like and target other elements than the new elements for styling.
Use the universal selector (*) to target the right element.
* { margin:0; padding:0 }
html { background:silver }
body { border:solid; background:white; margin-left:10em }
ul { position:absolute; top:0; left:0; width:10em }
Now of course you're going to use other ul elements than the navigation, so how do we get more specific on which element to target? The obvious solution is to set a class or id on the ul element, but there's another solution which might be more convenient in some cases, which brings me to...
Using the universal selector
Depending on the situation, and whether you care about IE6 or not, you can use the universal selector to target the element you want.
...and you want to style the p that is in header, you would do this in the normal case:
article header p { font-weight:bold }
But in IE, the article, header, h1 and p elements are all siblings, so the selector wouldn't match.
So then one would expect this to match, but it doesn't (IE doesn't allow selecting unknown elements using type selectors):
article + header + h1 + p { font-weight:bold }
However, this matches:
body > * + * + h1 + p { font-weight:bold }
Using noscript
The above techniques shouldn't mess up other browsers (or IE when scripting is enabled), however if you prefer (or if something would screw up) you can use a separate style sheet for IE when scripting is disabled by just using the following markup:
The above techniques might not be very scalable or might well impact maintanence, but the point of this article is to show that it is possible to use the new elements while still supporting IE with scripting disabled.
The WHATWG has how published a snapshot version of the HTML5 spec for review. Ian Hickson wrote to the WHATWG mailing list:
Last November, as part of the feedback on the W3C HTML WG charter, I wrote
an e-mail saying that I thought a realistic timetable would have a
first working draft released in October 2007.
We don't really need archived copies with the way the WHATWG works, since
everything happens in the open with a Subversion interface and everything,
but, I figured that I should "publish" an archived copy anyway, so today I
put out a frozen "call for comments" draft:
If anyone was hoping for a semi-stable version to start reviewing the
draft, I would say that this is it. We're pretty much feature-complete at
this point, which is to say I don't think we'll be adding any major
features to HTML5 going forward (though of course minor features like
additions to certain APIs are likely to still occur).
...which has about 3700 issues in it. The next order of business is simply
to go through all of those issues. I've been tracking the issue count
since early October, and at the moment the count is reducing at a rate of
about 7 a day, which works out to being about a year and a bit of solid
work, which puts us on track to reach Last Call in 2009, as I predicted in
the aforementioned e-mail.
I'd like to thank everyone here in the WHATWG community for helping make
this work fun and pleasant. It's really nice to be able to work in such a
friendly atmosphere. I hope the coming year will continue the same way!
Cheers,
I'd like to thank Ian for his hard work on editing the spec. Keep it up! 🙂
Posted in WHATWG | Comments Off on Call for Comments
