Using schema.org for SC1.3.4 #653
Comments
|
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 ***@***.***> 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
<#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
|
|
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. |
|
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/. |
|
(Official WG response) 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. |
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.
The text was updated successfully, but these errors were encountered: