– DRAFT –
Architecting for Privacy, Media Accessibility and Product development: the video element

nigel: Summary for this is to think about architectural models for maintaining privacy in accessibility
… referncing the video element in particular
… allow user choices without fingerprinting
… context, people with barriers to access need to adjust display settings
… the lack of consistency in how those settings are done is a problem in itself
… user settings made portable between systems
… ITU is working on this, as part of the UN
… Intersector Rapporteur Group Audiovisual Media Accessibility
… working on the common user profile
… in the US the FCC has the CTA, working on something similar to allow users to set their preferences for media
… a standard format document made available to apps, websites, etc
… the user can edit and share it
… and different settings for different scenarios, like screen size or type
… which is very powerful, but there is risk
… the document has high entropy, user fingerprinting is very possible
… privacy is a concern
… to meet user needs, product developers must suit their output to the user needs
… they have a legitimate need to know how users use the features
… knowing data like how people prefer captions would help with product decisions
… it's difficult to polyfill things on areas like the video element
… how can we improve accessibility while also ensuring privacy, and the communication of user needs to product developers
… mentioning the video element
… key features
… video does not take child elements
… it's a shadow host, but cannot have a shadow tree attached
… there is no parent-child layout
… try to put content on top of the video
… it's clunky if not impossible
… you need to create sibling or related elements and make them work together through CSS
… ever tried tracking the video as the page changes?

nigel: no general purpose polyfills
… that tracks data and uses it, but it's difficult
… you still cannot access the user accessibility settings
… the only way to see things, you can access through captions in VTT, entry and exit handlers
… good for privacy but difficult for product improvement
… two choices, <track> children with VTT captions and browser renders
… any default styling is possibly overridden or tweaked
… option 2, create a separate container element and render captions, use CSS to colocate, customisation is whatever the page offers
… you can get data
… but no relationship to existing accessibility preferences.
… tension between user and product owner needs, but there is no real tension
… same end goal

nigel: Here are my ideas
… allow the <video> element to accept a shadow tree
… use polyfills and reporting
… or allow the user to relax strict constraints on access to user settings
… ideally for pages where the user is already signed in or authenticated
… trusted and signed web components
… some components that have special access to user settings, where it's trusted
… user could authorise its use
… DOM implementation is authorized by the UA
… what do native apps do?
… Android and Apple have a API for fetching caption settings
… is privacy not important???
… in apps there may be a moderation process
… app developers report that the usage of data is likely not checked
… discussion time!

eeeps: Are you familiar with the W3C design guidelines that make it clear that UAs should not know if assistive tech is being used?

nigel: I agree with that, using accessibility settings to identify the user should not happen

eeeps: Working on accessibility API to allow canvas to interact

Cyns referenced this design principles link: https://w3ctag.github.io/design-principles/#do-not-expose-use-of-assistive-tech 2.9. Don’t reveal that assistive technologies are being used

eeeps: what do you need to see in the browser rendering of captions to make this less necessary?

nigel: There are problems with the browser rendering captions, but I don't think that will change this
… how do I, a product owner, improve things for users?
… avoid making the same adjustments over and over again
… but I can't find that out

eeeps: And the regulatory work?

nigel: ITU has broader scope than television, it's focused on audiovisual a11y, the FCC's work is mainly focused on TV

Eric: your first suggestion, ould it be possible for the page to tell the browser about the elements that it's using for captions?
… then the user style could be applied
… that is a possibility
… we made a proposal for a generic queue API
… it's in WebKit as an experimental feature
… allows people who can't use WebVTT to take the captions they load themselves to hand over to the browser to use
… use the user preferences
… it doesn't address the need to know what the users does

nigel: No, not on the macro level

eeeps: Question of receiving a11y preferences
… in CSS, prefers media queries
… specifically chosen to do specific things in certain situations
… prefer high contrast some or all of the time
… having a prefers- media query with too small a scope, but it is one way to present an adapted page
… in terms of reporting, there was a proposal this week about a reporting API
… aggregate reporting with many use caes

gendler: The inital point raised about design principles trumps my point, any signalling here could raise that issue

The Media Features reference that eeeps mentioned https://www.w3.org/TR/mediaqueries-5/#mf-user-preferences

gendler: I wanted to add a smaller note on one of the proposals, two

<cyns> Web Design Principles https://w3ctag.github.io/design-principles/#do-not-expose-use-of-assistive-tech

gendler: allowing users to relax constraints when they are signed in
… that relationship doesn't mean they give consent
… we want confirmed consent and clear communicated
… stages of "signed in"

nigel: How does the browser know you're signed in

Eric: We could end up with sites insisting on you being signed in to allow things
… privacy tracking in Safari, some major sites require it be turned off to use the site

gendler: All of the criticism is not to say thisn't worthy topic
… in this case, there's no way to bridge the conflict

<Zakim> jcraig, you wanted to share a somewhat-relevant link to Nigel's response about AT can be tracked https://github.com/w3ctag/design-principles/issues/293 and to respond to the media feature reference

jcraig: I chaired the design principles work, not sharing with AT
… somewhat relevant, you mentioned it can already be done, most core architectural features leak a11y data
… I had hoped we could discuss it with the TAG
… media features, I am partly to blame
… there are a lot of media features we would like to see but need CSS to adopt a privacy model
… the ones that are shipping
… enough people without disabilities use these features, that the fingerprinting risk is reduced
… the other history is that there are a lot of times that a preferences API has been recommended
… I wrote IndieUI: User Context and many were vehemently opposed
… even though I had a security model
… and there are things we cannot do
… I'd like to offload the preferences to the browser, the trusted agent

mfoltzgoogle: I think you earlier mentioned using the shadow DOM
… how many issues were DOM issues vs styling issues
… users expressing style preferences is different, more clarity is needed on the issues

nigel: A few different responses
… no because design principles
… if its rendering, we should do rendering better
… theres something outside those
… I mentioned a web component with a trust model built in
… user needs to confirm trust, and the component handles what data it needs
… I wonder if this might be the territory we're in
… it's possible to anonymise, aggregate the data
… could have user preference for the component
… some intermediating

Wilco: In what situations would a browser include or expose prefrences on captions but not have those preferences in the video element
… not sure how we get into this situation
… I don't see the need to polyfill that based on browser information
… browser extensions could fill this
… for privacy, a note, anything in the light DOM can be queries
… it would need to be in the shadow DOM in order to avoid leaking privacy data
… very fundamental change

cyns: is the goal analytics?

nigel: yes

cyns: site side benefit is analytics... user benefit is consistency/accessibilty

nigel: yes, but not just site (e.g. bbc) consistency.

cyns: talking about brand consistency and system view conventions... sometimes at odds with each other?

mbgower: how should we provide further feedback Nigel?

<mbgower> https://www.w3.org/2022/Talks/TPAC/breakout-sessions/private-a11y/private_a11y_breakout.html

<jcraig> nigel: Core question for this session

<jcraig> What architecture can allow users to set preferences in a reusable way without exposing them to unwanted fingerprinting, while allowing content/app/page providers to get useful product data about accessibility feature usage, and allowing for creative/improving solutions for accessibility?

nigel: I think it's very clear that no one is trying to ID individual users or make them do something for a site to work
… so the vague proposal I'm hearing: make sure everything is in the shadow dom
… it felt like we were heading towards a browser extension. I'm not sure if that's acceptable. It doesn't feel like the same level of consent prompt.
… Is that even feasible? Can a page say "i want a browser extension"?

jcraig: So your suggesting getting a third party extension?

nigel: yes, it would be able to write into the shadow dom of the video. a trusted component

jcraig: so is that does that exist or is it theoretical?

nigel: I tried to make something for caption rendering. the BBC is unaware of user settings for captions.

nigel: it's great we do our own caption rendering and we get data about size choices

nigel: but the user does't want to have to keep doing that

<jcraig> cyns: think about threat modeling, with the assumption that the web site is a bad actor. user agent should protect the user settings from that bad actor.

<gendler> +1 cyns

<jcraig> nigel: trying to use constraints as a compromise to serve both users and site authors better

<jcraig> nigel: tried to explore relationship b/w user, page, and browser

<jcraig> nigel: and to clarify, there is no existing extension that provides this functionality

<jcraig> ITI and CTA are discussion shared terminology of user settings… but no format or API

<jcraig> cyns: where does that data lie?

<jcraig> jcraig: it doesn't yet... CTA-2115 and ITI??? are shared vocab exercises

<jcraig> gendler: extension ides, if everyone is sending a signal of accessibility it would not give a specific pref, but still show a general needs. could be obfuscated by injecting noise to the page.

<jcraig> nigel: why would the page need to know?

<jcraig> gendler: page can infer from use of a third-party extension that user may have an accessibility need

<eeeps> https://docs.google.com/presentation/d/1jouxxwqf_l2YvGL-NpUHMEI9Af84QabYMHXvpbCsDjE/ is the aggregated reporting proposal (freshly proposed yesterday in the WebPerf WG)

<jcraig> nigel: something about abstracting the data usage where the page could not get anything from the extension

<jcraig> wilco: google prototypes features through extensions. does that out the user of those extensions?

<jcraig> cyns: we're pretty careful about it

<jcraig> wilco: I'm gonna check ;-)

<jcraig> nigel: thanks to all... I hope we can share the goal of finding a route to a good solution.

<jcraig> nigel: worth repeating: this is not an attempt to find user identifiable information.... just aggregate

<jcraig> wilco: consider a community group with extension developers and browser developers?

nigel: I want the best for users