- From: John Foliot <john.foliot@deque.com>
- Date: Tue, 28 Jan 2020 13:14:59 -0600
- To: Charles LaPierre <charlesl@benetech.org>
- Cc: Rachael Bradley Montgomery <rachael@accessiblecommunity.org>, public-personalization-tf <public-personalization-tf@w3.org>, Lisa Seeman <lisa.seeman@zoho.com>, Janina Sajka <janina@rednote.net>
- Message-ID: <CAKdCpxzNtLkqSC6pTGtzp9p-Pa2fCriYzeVoDeG1hg1y+gyYyA@mail.gmail.com>
Hi Charles, Having investigated a similar Technique during TPAC 2017 (Burlingame) when attempting to advance earlier SC in the WCAG 2.1 time-frame, I knew that a) it *was* doable, however b) we lacked the appropriate taxonomy terms at Schema.org at that time (and creating new terms was out of scope for that activity - one of the reasons why our TF was stood up), and c) it is indeed a verbose solution. However, in the context of the current proposed WCAG 2.2 Success Criteria (outside of this TF's remit), it is a viable technique *today*, whereas our FPWD is far less so. We've not got any real implementation experience, zero public feedback to date, and, for me, a looming sense of "hurry up or we will miss the bus", to which I can only reply, "there is another bus coming soon enough, let's get it right, and not be too hurried" - is all. I believe Rachel plans on taking this back to the COGA folks and AGWG, at which point it no longer becomes a significant issue for the Personalization TF. Once our specification reaches maturity, we can always help AGWG to add alternative, less verbose techniques to the new proposed SC. JF On Tue, Jan 28, 2020 at 9:41 AM Charles LaPierre <charlesl@benetech.org> wrote: > That is definitely news to me, I was told that schema.org metadata was at > the page level. > Now that being said, that is a lot of overhead to inject that metadata at > the element level since it is quite cumbersome which I believe is why > traditionally that was left at the header of HTML pages. > > Thanks > EOM > Charles LaPierre > Technical Lead, DIAGRAM and Born Accessible > Twitter: @CLaPierreA11Y > Skype: charles_lapierre > > > On Jan 27, 2020, at 2:58 PM, John Foliot <john.foliot@deque.com> wrote: > > Hi Charles, > > I'd like to check that assumption a bit please. I had a chat with Chaals, > who as you know is one of the co-Editors of the Microdata spec, and he > confirms that Schema.org metadata can also be used more granularly than > that. In fact, I shared some code with him related to using Schema and > Microdata with video (explicitly), and he agreed that it was correct (well, > he helped me correct it). The issue (as is often the case) is tooling: > today the only real tooling that consumes and uses this stuff is the search > engines. But as a technique, this is indeed valid code: > > <video controls itemscope="" itemtype="https://schema.org/VideoObject"> > > <meta itemprop="accessibilitySummary" Content="A how-to video on > adjusting your thermostat, it also provides alternate captions using > simplified language"> [1] > <meta itemprop="accessibilityFeature" content="displayTransformability"> > [2] > <meta itemprop="accessibilityHazard" content="noFlashingHazard"> > > <source src="sample.mp4" type="video/mp4"> > > <track default kind="captions" srclang="en" > src="/media/examples/friday.vtt"/> [3] > <track kind="captions" srclang="fr" > src="/media/examples/friday_french.vtt"/> > > > </video> > > > [1] This is for the search engine use-case - it allows for filtering there > [1a] we really don't have a mechanism today to identify "simplified > language", the options are mostly relegated to different languages > (English, French, German, etc. - but requesting a new @kind value could > likely happen, especially with appropriate use-cases) > [2] with a fixed list of features and hazards, tooling can then start to > use "whitelists" and "blacklists" - adding harmful video content to a > blacklist, and/or adjustable content to a whitelist for example > [3] https://html.spec.whatwg.org/multipage/media.html#the-track-element > > JF > > On Mon, Jan 27, 2020 at 2:57 PM Charles LaPierre <charlesl@benetech.org> > wrote: > >> Hello Rachael and all, Yes I am very involved in this but this metadata >> that John pointed to via schema.org is at the page level or what we are >> using it for is at the EPUB (electronic book) level for the entire book. >> Element level semantics hasn’t really been defined which is why we need >> this level of support with personalization and semantics at the element >> level. >> >> Thanks >> EOM >> Charles LaPierre >> Technical Lead, DIAGRAM and Born Accessible >> Twitter: @CLaPierreA11Y >> Skype: charles_lapierre >> >> >> On Jan 27, 2020, at 2:13 PM, John Foliot <john.foliot@deque.com> wrote: >> >> > Can scheme (Schema - JF) be applied at an element level? >> >> Uhm... sort of, but it's a bit verbose. I looked at it in the context of >> SC 1.3.5, and at that time the biggest issue was the lack of taxonomy >> (values). However, using Microdata, yes, you can scope Shema.org >> <http://shema.org/> values to elements (or blocks) on a page. >> >> When I say verbose, it's because to use Microdata in that fashion, you >> need to scope the application (itemscope), you need to indicate the type >> (itemtype), and then you need to apply the relevant property values >> (itemprop). Looking quickly, I found this example >> <http://schema.org/accessibilityHazard> for a book (which was, I >> believe, Benetech's primary focus). None-the-less, I think it is a good >> illustration of the pattern and application of Microdata in this use-case: >> >> >> 1. <div itemscope=" " [I beleive because this is in a <div> it is >> inferred as scoped to the div - JF] itemtype="http://schema.org/Book"> >> 2. <meta itemprop="bookFormat" content="EBook/DAISY3"/> >> 3. <meta itemprop="accessibilityFeature" content= >> "largePrint/CSSEnabled"/> >> 4. <meta itemprop="accessibilityFeature" content= >> "highContrast/CSSEnabled"/> >> 5. <meta itemprop="accessibilityFeature" content= >> "resizeText/CSSEnabled"/> >> 6. <meta itemprop="accessibilityFeature" content= >> "displayTransformability"/> >> 7. <meta itemprop="accessibilityFeature" content="longDescription" >> /> >> 8. <meta itemprop="accessibilityFeature" content="alternativeText" >> /> >> 9. <meta itemprop="accessibilityControl" content= >> "fullKeyboardControl"/> >> 10. <meta itemprop="accessibilityControl" content= >> "fullMouseControl"/> >> 11. <meta itemprop="accessibilityHazard" content="noFlashingHazard" >> /> >> 12. <meta itemprop="accessibilityHazard" content= >> "noMotionSimulationHazard"/> >> 13. <meta itemprop="accessibilityHazard" content="noSoundHazard"/> >> 14. <meta itemprop="accessibilityAPI" content="ARIA"/> >> 15. <p>On screen content here</p> </div> >> >> >> Hope that helps. >> >> JF >> >> On Mon, Jan 27, 2020 at 12:55 PM Rachael Bradley Montgomery < >> rachael@accessiblecommunity.org> wrote: >> >>> John, >>> >>> Thank you for sending this. I can think of examples where element level >>> content would benefit from tags such as these. For example, a news page >>> might include a video report, transcript, and a second video of taped >>> footage. The report and transcript might be written to avoid upsetting >>> content but the taped footage of what happened might need to be marked. >>> >>> Can scheme be applied at an element level? >>> >>> Best regards, >>> >>> Rachael >>> >>> On Mon, Jan 27, 2020 at 1:43 PM John Foliot <john.foliot@deque.com> >>> wrote: >>> >>>> Hi Rachel, >>>> >>>> Thanks for the clarification. Are y'all aware of this already? >>>> >>>> https://schema.org/accessibilityFeature >>>> and this: >>>> http://schema.org/accessibilityHazard >>>> >>>> I suspect the use-case(s) you are envisioning would be to use metadata >>>> at the page level (versus the element level, which is where Personalization >>>> is currently headed). >>>> >>>> I'd personally rather see COGA efforts focus on the existing >>>> solution(s) (which I think are mostly lacking in tooling support), rather >>>> than trying to tease it out of our Personalization work (fun fact: Charles >>>> L. was actively involved with that work as well, right Charles?) >>>> Additionally, because Charles was previously involved, I'm sure he could >>>> assist if one or more specific "hazard values" is currently missing (I >>>> assert it is easier to build on top of existing effort, rather than start >>>> fresh elsewhere). >>>> >>>> Schema dot Org already has strong support with the major search engine >>>> vendors, which includes Google, Microsoft, Yandex, and Baidu. >>>> >>>> JF >>>> >>>> On Mon, Jan 27, 2020 at 10:12 AM Rachael Bradley Montgomery < >>>> rachael@accessiblecommunity.org> wrote: >>>> >>>>> Hello, >>>>> >>>>> I took us down the wrong track with regards to video and the mental >>>>> health paper and I think you should revisit the issues Lisa raised at >>>>> another Personalization meeting. There was too little time left today so I >>>>> didn't jump back in. For personalization, I believe the suggestions are: >>>>> >>>>> 1. To consider adding a tag that identifies content that could trigger >>>>> anxiety, PTSD or other mental health conditions. This would add to the >>>>> sense of safety on the web for some individuals. >>>>> 2. To consider adding a tag that indicates alternative versions of the >>>>> same content. >>>>> >>>>> Lisa - please correct me if I have misunderstood. Thank you again for >>>>> the discussion on today's call. I will update you as Essential Controls >>>>> continues. >>>>> >>>>> Best regards, >>>>> >>>>> Rachael >>>>> -- >>>>> Rachael Montgomery, PhD >>>>> Director, Accessible Community >>>>> rachael@accessiblecommunity.org >>>>> >>>>> "I will paint this day with laughter; >>>>> I will frame this night in song." >>>>> - Og Mandino >>>>> >>>>> >>>> >>>> -- >>>> *John Foliot* | Principal Accessibility Strategist | W3C AC >>>> Representative >>>> Deque Systems - Accessibility for Good >>>> deque.com >>>> >>>> >>> >>> -- >>> Rachael Montgomery, PhD >>> Director, Accessible Community >>> rachael@accessiblecommunity.org >>> >>> "I will paint this day with laughter; >>> I will frame this night in song." >>> - Og Mandino >>> >>> >> >> -- >> *John Foliot* | Principal Accessibility Strategist | W3C AC >> Representative >> Deque Systems - Accessibility for Good >> deque.com >> >> >> > > -- > *John Foliot* | Principal Accessibility Strategist | W3C AC > Representative > Deque Systems - Accessibility for Good > deque.com > > > -- *John Foliot* | Principal Accessibility Strategist | W3C AC Representative Deque Systems - Accessibility for Good deque.com
Received on Tuesday, 28 January 2020 19:15:42 UTC