search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
140 stars 55 forks source link

Using schema.org for SC1.3.4 #653

Closed guyhickling closed 6 years ago

guyhickling commented 6 years ago

One of the proposed "sufficient techniques" for SC 1.3.4 "Identify Common Purpose" is to use the Schema.org item types to tell browsers and AT what interactive items are for, so that they can provide extra cues to users - such as displaying symbols on screen to further identify interactive fields to the user.

However schema.org was created for the search engines. Up to now schema.org has had no relevance to browsers that I know of - they presumably just ignore those items.

So I have to ask the same questions that I asked recently about the suggestion of using the HTML5 autocomplete attribute for the same purpose. Have any browsers started to do anything with schema.org item types for accessibility purposes? Do they plan to? Is anyone at W3C working with them to achieve this? If browsers - and AT - are to provide extra cues to users when they find schema.org types, that will be a huge new project for the browsers. Is that project underway yet?

The primary question in all this is, in telling developers to use schema.org types when WCAG 2.1 goes live, will we be telling developers to do something that will have no practical accessibility value whatsoever and just mean extra work for developers to no purpose?

There is no need here to ask developers to do this entirely on spec. Given that schema.org markup is already out there on many web pages for SEO purposes, let the browsers first do the job of picking up that data and using it for accessibility purposes. If they do that - and I suspect that might be a big if - that will be the time to start asking developers to do all the extra work to implement it as a technique under this SC.

johnfoliot commented 6 years ago

Hi Guy,

You have hit upon the chicken-and-egg problem: no tools for the solution, because there is no solution for the tools.

Waiting for browsers to do something with metadata (and to be both frank and honest, 1.3.4 is only asking for inline metadata on a fixed list of controls - schema.org CAN be one metadata vocabulary, but any one will suffice if it meets the criteria) will see us waiting "forever". To get support for ARIA rolling, IBM quite literally paid to have Aaron Leventhal add that support to the Firefox browser (see: https://blog.mozilla.org/webdev/2009/07/02/improving-accessibility-through-aria/), so if history is to guide us, we'll still be waiting for a fully-formed chicken to arrive on the scene 10 years from now if we don't break that cycle. (Furthermore, "browsers" really don't do anything with ARIA, except pass along the added semantic to the accessibility tree, where AT - screen readers for the most part - then use that semantic data. So "browser support", while desirable, isn't the only way of measuring success here.)

Instead, there is a plan to work on a browser extension that will work with Schema.org and Microdata annotation (as one nice thing about that solution is that it will create unique and fixed attributes and attribute-values, which can then be used as CSS selectors), and using a customized "user stylesheet" in the extension, 'overlay' additional (standardized) icons/labels to those specified controls. While far from a fully robust system, it will be a solid enough Proof of Concept (I hope) to visibly demonstrate the value, and it is anticipated that AT vendors, once a sufficient corpus of marked-up content exists, will also pursue more robust and focused solutions. Remember that at the core, one key driver for this SC is towards Personalization, and so how the end-user will personalize their screens remains something of an unknown: however if I can tell you enough about the control using metadata, then you as the end user will in time be able to accomplish more granular and finessed customizations.

But first we need to hatch the egg...

HTH

JF

On Tue, Jan 2, 2018 at 6:19 PM, Guy Hickling notifications@github.com wrote:

One of the proposed "sufficient techniques" for SC 1.3.4 "Identify Common Purpose" is to use the Schema.org item types to tell browsers and AT what interactive items are for, so that they can provide extra cues to users - such as displaying symbols on screen to further identify interactive fields to the user.

However schema.org was created for the search engines. Up to now schema.org has had no relevance to browsers that I know of - they presumably just ignore those items.

So I have to ask the same questions that I asked recently about the suggestion of using the HTML5 autocomplete attribute for the same purpose. Have any browsers started to do anything with schema.org item types for accessibility purposes? Do they plan to? Is anyone at W3C working with them to achieve this? If browsers - and AT - are to provide extra cues to users when they find schema.org types, that will be a huge new project for the browsers. Is that project underway yet?

The primary question in all this is, in telling developers to use schema.org types when WCAG 2.1 goes live, will we be telling developers to do something that will have no practical accessibility value whatsoever and just mean extra work for developers to no purpose?

There is no need here to ask developers to do this entirely on spec. Given that schema.org markup is already out there on many web pages for SEO purposes, let the browsers first do the job of picking up that data and using it for accessibility purposes. If they do that - and I suspect that might be a big if - that will be the time to start asking developers to do all the extra work to implement it as a technique under this SC.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/653, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c8pUIIBLrYpRvKJGqzRK2Gh5FNmlks5tGseNgaJpZM4RROmW .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

guyhickling commented 6 years ago

Hi John, thank you for answering, and I do appreciate the difficulty.

My problem is that I have clients who pay me to do accessibility audits and tell them what to do to make their sites accessible. If I start telling them to use schema.org item types, some of the more aware clients are likely come at me and say "What browsers do anything with this?" And I will have to admit, well, actually none of them do! At which point no doubt some of them will go and find a new audit consultant!

I can see your argument about the chicken and egg situation. But schema.org is already in use for SEO, so (and assuming SEO people apply schema to input fields, the elements this SC is targeting) the browsers have a base of websites to apply their developments to. Then once the browsers have done that developers can start using it on all sites.

I don't think asking developers and IT departments, and testers and auditors, to go to a load of extra trouble to use any of the technologies mentioned in this SC is the right way to go about it - purely on spec that maybe 3 or 4 or more years down the road browsers will wake up and make some use of it in some way not currently clear. We already have enough trouble getting developers to use ARIA correctly, or even at all, and that's been around for years. (A good many of my clients, even ones really serious about accessibility, still can't get their heads around something as simple as the h1 to h6 hierarchy!!)

I am sorry to sound pessimistic, but I seriously think we may be in danger of subjecting developers to accessibility overload. (Let's face it, some are only grudgingly implementing the accessibility principles we already have under pressure from management.) Let's get the world all up to speed with ARIA before trying to move them on further!

In fact, I would suggest maybe a much better approach to this SC would be to add new attributes for this SC to ARIA, a tried and tested technology that people are already at least familiar with (and much less typing for developers than, say schema.org and some of the others). Rather than introducing several whole new technologies before they have learned the current one.

lseeman commented 6 years ago

Hi Guy

I agree with your suggestion that it should be supported by ARIA. In fact an ARIA module has been drafted for that purpose. See https://w3c.github.io/personalization-semantics/.
:)

awkawk commented 6 years ago

(Official WG response) The SC has been changed to focus on currently supported attributes, so browsers support this across the board: https://caniuse.com/#feat=input-autocomplete-onoff (There are some issues with browser implementations, but they do not appear to affect the autofill part of autocomplete.)

This aspect alone is very helpful to some people with cognitive issues.

For the aspect of adding icons for users (another goal of the SC) It is also worth noting that there are several implementations already: Chrome extension: http://accessibility.athena-ict.com/personlization.shtml Script: https://github.com/ayelet-seeman/coga.personalisation Website based implementation: https://a11y-resources.com/developer/coga-personalisation

These are at early stages and have been using the COGA semantics spec, but these can be updated to cover the autofill attributes as well, while the other aspects mature.

Overall, there is basic support for the proposal already, and people committed to expanding the functionality during the CR stage.

Given the user-need, and that this new version is far easier to implement, there does not seem to be an issue with including this SC at level AA.