Smaller polyfill

[jonathantneal]

This is a neat project, but the Polymer polyfill is overkill. A fairly robust polyfill could be written in < 500 bytes. For instance, this polyfill assigns the appropriate role and level to all headings in all modern browsers (read: IE9 and up) even when the DOM tree changes.

[peteboere]

+1

[matatk]

Your polyfill looks great; thanks for posting. It seems that all browsers since IE 9 will gracefully deal with an unknown element? I don't have the cycles for the next couple of weeks, but I look forward to exploring in detail how this behaves from the perspective of Assistive Technologies (ATs) such as screen-readers.

With <html5-h> we have two goals, which are sometimes at odds...

1. Create a universal heading element that works now (your polyfill does this, or gets very close).
2. Create a reference implementation that feels as much as possible like a native HTML element would, and matches a draft specification we're working on (looks like your polyfill may do this, possibly with further adaptation).

Some things it would need to be able to do that could perhaps be worked in...

• Allow people to set level manually (in the rare cases it makes sense) and have the heading stick to it.
• Have the default styling of the corresponding <hn> element.
• Degrade gracefully when the element or JS are not supported (this is why we had to make the "fallback" version of <html5-h> for now, which actually extends <h1> to implement the HTML5 Outline algorithm).

Polymer is certainly a barrier to entry -- though it would be interesting to compare the behaviour/any trade-offs associated with your polyfill for a site that's already using Polymer (I have not yet looked into things like how efficient and robust the DOM mutation observers it provides actually are, and implications of them on large pages). It'll be interesting to see how we could develop both approaches.

One challenge that appears universal is that of CSS specificity - would be interested to hear if you think there may be work-arounds for that (on the other issue threads).

[jonathantneal]

a universal heading element that works now

Polymer is a large library intended to work in the latest version of evergreen browsers. The legacy polyfill works in IE6+ (and still updates on DOM mutation). It’s 1322 bytes uncompressed and documented, which means it should be easy for other developers to see exactly what’s going on.

allow people to set level manually

Interesting idea. What is the use case?

Have the default styling of the corresponding element

Default styling can be achieved in all browsers with this stylesheet.

Selector specificity will be an issue. Adoption of h may require a paradigm shift. Even the proposed :heading(N) is a pseudo class, which means it would have more specificity than h or h1. I don’t see a way to work around this without introducing an alternate kind of pseudo element, with either no specificity (like :not) or element specificity (like h1).

Degrade gracefully when the element or JS are not supported

This can be done in the last line of the polyfill by changing the "h" string with "h1", "html5-h", or any other element name you prefer.

[stevefaulkner]

i haven't looked at this closely. My current leaning is small polyfill, extend h1 and keep custom element nomenclature

[matatk]

In answer to @jonathantneal's question on the now-closed #30... we definitely want to take this forward and thanks again for sharing your polyfill. I have still not created the time to test it in detail with the accessibility APIs (though, again, I don't anticipate major issues) -- after that's done, would you be happy in principle for us to adopt it?

One of our goals is to hopefully get this thing specified and adopted formally. Haven't looked too far into this yet, but that may be helped by keeping the Polymer version around and in-synch, because it uses and exposes the up-and-coming official APIs for doing (Custom) Elements, but for general use I think the polyfill looks a lot better (again, need to satisfy my curiosity with respect to its interaction with accessibility APIs).

[matatk]

I've (finally, sorry for the lag) been able to start testing the polyfill in some detail -- the results are quite interesting; some of the screen readers appeared to have issues with identifying/moving between the headings, which I was not expecting.

Test details and results:

• I used this test HTML file from a gist I forked from @jonathantneal.
• I served it locally using Jekyll (jekyll serve --watch --host machine_name).
• Google Spreadsheet with results so far.

Some thoughts:

• I think that the NVDA+IE thing may be bug in NVDA; it is probably querying the DOM and expecting an element named <hn>.
• I do not know what is causing the heading back-skipping problem at the moment. I have seen problems like this (where accessibility info is missing) occur with other types of elements, if an element is the first one on the page, so it could be a screen reader bug.

Still need to test on other browsers and try to see more about what the accessibility APIs are getting from the browsers...

[matatk]

I have just restarted my VM and tested it again and also with the Polymer version of <html5-h>, I found:

• The bug whereby JAWS can't skip back from "Heading text level 1" to "Ramones..." has disappeared -- I have been getting some "wonky" results from both NVDA and JAWS, but thought I'd finally homed in on what the true situation is. Anyway, I have updated the spreadsheet to remove that error (for now).
• The same issues as are in the spreadsheet at the time of writing actually apply to the Polymer version too, so it certainly seems like screen reader or browser bugs are the most likely explanation.

As a result, it is looking like the accessibility of the polyfill approach is not going to be an issue (as hoped and expected). But we do need to get to the bottom of the possible screen reader or browser bugs uncovered by this exercise before we can consider either approach accessible.

I would very-much like to be able to recommend @jonathantneal's polyfill as the code is so simple and elegant -- looks like we'll be able to do that in the not-too-distant future!