#476: Personalization Semantics Explainer and Module 1
Discussions
2020-11-16
Reviewed progress, generally happy with the task force's response. Want to clear the advertising angle with Alice. Rossen will bring up at breakout B.
2021-01-Kronos
Rossen: We have made it clear that we agree with the use cases and that these problems need to be solved, but we don't agree with the proposed solution.
Alice: I think we unfortunately have to give them some feedback that they're not going to be happy with.
... We've pointed out that their work identifying the problems to solve is extremely good, and that the problems are real and should be solved.
... However, the shape of the solution as an ARIA-like vocabulary doesn't seem like a good fit.
... ARIA had the characteristics that it was based on an existing vocabulary (MSAA), and was intended to be consumed by a single class of technologies (screen readers, later expanded to other types of assistive technologies.)
... In contrast, this vocabulary seems like it would have a wide range of consumers, and it's not clear that those consumers have been brought in as stakeholders to this design process.
... We suggest that instead of trying to solve all of these problems with one solution, that you could take the excellent work already done identifying problems, and look at solving them individually, working with the relevant stakeholders.
... Some of these problems may be "stickier" than others; for example, trying to come up with a system to allow users to avoid unwelcome distraction from revenue-generating ads is going to involve buy-in from the publishers who need that revenue in order to keep operating as a business.
... However, other problems, like annotating words with the relevant Bliss or other symbol, seem very well scoped in terms of user need, authoring responsibility, and assistive technology implementation requirements.
... Not all of these solutions may even need to go through a standardisation process immediately, but may be better suited to incubation to allow prototyping and rapid iteration as a collaborative process with the various stakeholders, before settling on a standard.
... We know this is not the feedback you were likely hoping for, but we would like to emphasise how rare it is that we get a proposal with the level of work put in to user needs as we have seen here, and that this is one of the most critical parts of the design process.
... We would love the opportunity to continue working with you on better scoped proposals to address subsets of the user needs you have identified, including very early stage ideas.
Rossen: We can use this opportunity to suggest that rather than shying away from media queries, that MQs may work well for some subsets of these problems.
Alice: Posted comment.
Rossen: Posted follow-up around working with CSSWG and media queries.
OpenedFeb 19, 2020
Hello TAG!
We are requesting a TAG review of Personalization Semantics Explainer and Module 1 - Adaptable Content. It contains supporting syntax that provides extra information, help, and context. We aim to make web content adaptable for users who function more effectively when content is presented to them in alternative modalities - including people with cognitive & learning disabilities.
Our wiki and getting-started page.
Security and Privacy self-review: PING review
GitHub repo: Repo and issues
Primary contacts (and their relationship to the specification):
-Charles LaPierre charlesl@benetech.org (Personalization Taskforce co-facilitator) -Lisa Seeman lisa.seeman@zoho.com (Personalization Taskforce co-facilitator) -Janina Sajka janina@rednote.net (APA chair)
Organization(s)/project(s) driving the specification: Accessible Platform Architectures (APA) Working Group - Personalization Taskforce
Key pieces of existing multi-stakeholder review or discussion of this specification: Taskforce discussions and stakeholder discussion (such as wiki vocabulary-in-content discussion and wiki symbol discussion.)
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): Beyond the discussion in the wiki there is also Easyreading and Firefox alpha from our demo at TPAC 2019 in Japan.
Special considerations: We would like advice on porting from the "data-" prefix to a more permanent syntax in CR. Should we suggest a prefix or just plain attributes? Note as more modules are produced we could have a sizable number of attributes.
Further details:
We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback