Hello. First of all, thank you very much for creating HTML5 Accessibility.

I would like to know if the page will be updated with the results adapted to the new versions of the browsers.

For example, the table shows the test results for Safari 13. However, Safari 16 has been out for quite some time now.

The same goes for the other browsers.

Presumably Chrome supports this as it has a green check and the linked bug is marked as fixed, so note should be updated. (not sure best way to verify if FF or Chrome support a feature)

All the checkmarks etc are background images. In windows high contrast mode they all disappear and the equivalent text is not shown. Either use content images (::before{content:....}) , regular inline images with alt text or add a high contrast detection routine which shows the text instead when in high contrast mode.

I currently need to check the support for older browser versions, especially FF 45.7 on Windows 7. Any advice on how to get this information?

Thanks in advance.

This element is supported by Chrome and Edge. It was removed from the W3C version of the spec but remains in the WHATWG version. We (Edge) implemented it because we wanted to be interoperable, and there is usage due to being in Chrome. No browser supports "datatime" (sans-local). My understanding is the local version has more use cases too and less problems, but I don't know the details myself.

When we do the work to firm up our date control accessibility to remove any rough edges, we'll be doing the same for datetime-local.

Some critical background images are missing when in Windows High Contrast Mode.

• browser logos at the top,
• feature support key.

I've added screen shots in IE11 on Windows 8 for each. I also added a screen shot of a border overlap in the footer.

I understand that in later versions of Edge background images will be displayed when a user is in Windows High Contrast Mode.

Both IE and Edge do not support details and summary.

Can you add a status for SVG accessibility status in browsers (like https://www.paciellogroup.com/blog/2013/12/using-aria-enhance-svg-accessibility/)?

Update http://www.html5accessibility.com data for Safari 10 in macOS Sierra (10.12.x) and iOS 10.x

Validating the page shows that there are currently two stray closing tags. An extra </td> on line 582 (after the "Accessibility Support" for the <video>), and </code> on line 1357 after the 'menu' text for <toolbar>.

I can run this sometime later this week.

Test for subDOM and why Safari gets partial in current version of HTML5A11y:

“IE, Edge, Chrome, Firefox: supports the accessible canvas element sub-DOM.
Safari: supports the accessible canvas element sub-DOM. Note: VoiceOver does not appear to announce text in canvas sub-DOM.”

As Safari wasn't listed in the first, line, I wasn't sure if it was suppose to say Safari doesn't support Sub-DOM.

Either way this needs re-testing to make sure sub-DOM still doesn't work in Safari, and if not we need to add a link to a bug report for this, so it is clear why Safari gets partial and so a fix can be tracked.

There is a not about development on Safari for Windows.

Safari on Windows is no longer included as there is no active effort to implement accessibility support in this browser.

Things is, there is no active development for Safari on Windows period. Shouldn't the note reflect that?

I have a mostly complete test run for this. Just double checking some tests.Will make a PR proposal later this week with that data.

Note this isn't Edge 14 (currently in development), which includes the new accessibility work. The test only includes released browsers.

Great Edge 80 is added but it doesn’t make sense to compare a browser released in 2020 to counterparts released in 2017, with FF being even a beta version.

Any chance the scores can be recalculated to a March or April 2020 baseline?

Seems a bit like cherry-picking results and I couldn’t help but notice design and development is in the hands of David Storey & Melanie Richards; both working for Microsoft.

Both the expand button and the code element in the row header cells in the tables are inline so the text gets concatenated without a space between in the accessible name calculation. (at least it does in FF anyway - you can check in the DOM inspector)

So my row header is "expandarticle"

Either add a space or make one of the elements a block level element.

The word expand is added for each button. While not a WCAG failure as there is context in the table cell, it would be much better if this text actually included what they were expanding.

once done, ready to publish update on html5accessibility.com

Running https://thepaciellogroup.github.io/AT-browser-tests/test-files/time.html in current stable (60.x.x.x) Chrome (on Win, macOS, Android) the <time> element is shown as "not supported". However, quick test with TalkBack on Android confirms that it does indeed work correctly (e.g. in TM-001 is announces "October 28 2015, time").

From Chrome 62 onwards it is supported. Worth adding a note?

Update the placeholder attribute test page to reflect that placeholder no longer participates in the accessible description computation as outlined in the HTML-AAM.

...where there is an existing bug. File bugs with vendor (or spec) where none exist, which is many of them. Need to discuss to agree if spec issue or browser issue for some of them and change accordingly.

Probably the icon is the same for both.

Suggestions:

• Link icon like the above, but more pretty (it has bad visual weight compared to others in github toolbar)
• A wee bug (this would be cuter, but then I link to platform status for missing features, which are kinda not bugs, so might need different icon for those if we went for a bug)

CC @melanierichards

I noticed that with the recent updates in April, Chrome and Safari now only show "?" question marks in the summary table:

Was this intentional, or is there just some missing/pending data or tests that need to be run?

A year ago, support seemed pretty good:

I tried to manually calculate things based on the detailed tables below, but wasn't able to figure out how the existing numbers were achieved... I'm guessing it was based on what tests were available at the time the browser was last tested. Any info you could share would be appreciated!

@dstorey how would you like your contributions acknowledged?

On this page:
https://www.html5accessibility.com/

The Dom Inspector (Firefox extension) link goes to
https://addons.mozilla.org/en-US/firefox/addon/6622/

Which Mozilla claims "Oops! We can’t find that page".

Now we have sub-criteria it makes it more clear how a score is broken down. But we need to decide when something is a fail and when it is partial.

Most logical is if anything implemented has at least one partial then it gets an overall partial.

It could be argued that this increases scores if for example the mapping is a fail (old fail score) but part of the naming algorithm like aria-label is supported. This inflates Safari's score somewhat with new criteria (if my testing was correct), and will perhaps increase score for Edge 13 and IE11 (section elements upgraded to partial rather than fail. It is unlikely to improve Edge 14 score (actually more likely to decrease it as testing naming/desc allowed us to find a bunch of bugs). It could be better to require at least one pass in sub criteria to get a partial or no fails (e.g. all partials would get partial). This would be harder to understand though that something with a partial is not partial.

@stevefaulkner what do you think?

Says IE implements but isn't accessible, but IE and Edge both don't support <time>.

(I'd update this myself but I'm not sure how the scoring effects the final score)

How is the percentage calculated?
Why does edge has 100% when it's missing 3 features?
If we count Partial and N/A as not supported it should be:

Whereas now it is:

Which might be correct if N/A isn't considered in the calculation (haven't checked), but I'd argue if a feature is not applicable for some reason it should be considered as not supported.

Both Chrome and Firefox get partial for mark, but there are bugs open that are not resolved about making the element accessible.

Would be good to have some clarity on what is partial support. Having same info as span seems like unsupported to me, as span has no semantic value and mark does. In the mappings spec span is various flavours of "group" (which i think is the default for unknown things?) while mark is various flavours of "text".

Seems to me both should be marked as unsupported (they're just getting the default role?) Is IE (which gets unsupported) any different?

Assuming the header note is correct still, Chrome reports header as a section role, rather than banner (if the most root element). This seems incorrect and should be rated as partial, especially if there is no difference between the global page header and child headers (article headers, section headers, etc.)

Would remove aria-pressed from the expand/collapse buttons. The attribute makes it a toggle button, in which case the label of the button shouldn't change.

From ARIA 1.1 APG 2.6 button [1]:

"Toggle button: A two-state button that can be either off (not pressed) or on (pressed). To tell assistive technologies that a button is a toggle button, specify a value for the attribute aria-pressed… Important: the label on a toggle button should never change when the state changes."

[1] https://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/#button

The logos you are currently using are outdated.

Here is a repo where you can find the latest browser logos (in high-res): https://github.com/paulirish/browser-logos

I don't see the <time> element on the page. Any plans to add it? Thanks.

I can likely run this test as I have a Mac. Will leave data here for someone else to double check rather than directly PR as I work for a different browser vendor.

https://webkit.org/blog/3302/aria-and-accessibility-inspector/

The following HTML5 features listed at http://www.html5accessibility.com/ have chrome bugs listed & linked in the Notes column which when visited now have a status of "fixed" but need to be verified:

• datalist
• figcaption
• email input, search input, telephone input, URL input (already marked as fixed, surely that can be removed now)
• output
• summary

The size is too big:

Tested with Safari 9.

https://connect.microsoft.com/IE/feedback/details/804723/html5-structural-elements-not-exposed-via-accessibility-api is closed and the URL provided for it being tracked 404's , need correct URL @dstorey

Something I think should be crucial it's information about screen readers support for HTML5 new accessibility features, including WAI-ARIA. Right now I don't know any website like HTML5accessibility with this kind of information.

Anywhay, just a tip 😛

The note mentions that Chrome supports as section role, and Firefox as a paragraph.

The later seems incorrect to me (a section is certainly not a paragraph, and usually contains multiple paragraphs plus other elements).

The former could be a typo, but if it isn't, there isn't a section role?

The spec says it should be mapped as a region (which maps to various things such as xml-roles:region or AXRoleDescription: 'region'), and discourages this if there is no accessible name (it isn't clear what it should map to if that is the case?)

Presumably Chrome/FF should be marked as partial or unsupported if they do not map to "region" or something related, or if they do, the note should be removed or updated.

https://bugzilla.mozilla.org/show_bug.cgi?id=494175

…where they exist. Hopefully works without having to change anything.

Note says "keyboard support suboptimal - cannot interact with individual controls. refer to Bug 494175"

This bug is still open. Not being able to interact with the feature via the keyboard is a fairly major accessibility issue. Presumably more so for people with motor issues. It at least shouldn't be considered fully supported.

Looks like they're all caused by missing > before no:

<a href="https://developer.microsoft.com/en-us/microsoft-edge/platform/status/meterelement/"no</a>

In Edge 16 and 17, the list entries are not displayed when using the keyboard.

For all browsers it is "not mapped" so not much point having it there.

Someone sent me the following redesign url: http://stevefaulkner.github.io/HTML5accessibility/.

I find it disturbing that there is no date when the testing was performed. IMHO data is not useful unless one understand's the timeframe. Steve's original page always included date information:
A work in progress: March 2016

Editors Draft march 7, 2016

WARNING! the data below is under continued revision

as a sighted keyboard user, i have trouble navigating through https://html5accessibility.com because the focus indicators are way too thin and not very noticeable. i had to squint and lean in very close to the screen to notice what was being focused.

screenshots from Firefox 117 on macOS 13:

consider using a solid outline with a larger outline-width.