Meeting minutes
Announcements and Introductions
matatk: We'll be going over agenda; talking with Brent from the AB about Process feedback; planning Maturity Model meeting (for tomorrow)
Feedback of process for Advisory Board with Brent
https://
matatk: what is the roadmap for the process
Brent: To oversee evolution of the process
Brent: To check improvements, understand gaps and give feedback.
Brent: Need to have horizontal review
Brent: We have multiple breakout sessions related to processes
Brent: Hear -> What people have to say -> Collect feedback -> Implement changes
Fazio: Publication processes is convoluted
Fazio: Wiki for the process was difficult to comprehend
Fazio: Not only what to do but how to do will help
Janina referenced: https://
Janina: Process documents are helpful
Brent referenced https://
Brent: Process group is community group for all to join
Roy_Ruoxi: Processes for uodating issues, other platforms
matatk: People should get aligned and informed about roles and responsibilities
matatk: WAI team has a very simple document related to processes
<chiace> https://
chiace: welcome kit like a document for new joiner
<Lisa> I am in the ag call. do you want me to switch?
Fazio: We have for a Maturity group document
participation
matatk: A lot of participation from invited expert side but need from member organization
matatk: Need simplified process for joining group
matatk: Presentation format for HTML, github interface complexity
matatk: Google docs can be a good option but not accessible for SR users
matatk: Sign up process is hard to get through
<Lisa> do we have a detailed agenda so we can tell what topic is being discussed when
matatk: Spec details like how many features are developed, what is published
<Lisa> or is it just github issues
Lisa It is related to feddback regarding processes at APA to Advisory board
Brent: horizontal review problem - at what point shall we consider document for standard is good to go
matatk: sometimes it is good in premature version or sometimes we need a detailed version. So it depends on the process
<JenStrickland> +1
Fazio: We can review at any point but just inform
Janina: Consider approach for developing first publishing draft
Lisa: Internationalization of processes, indentify user needs, better awareness about process of integration
matatk: where can we raise our feedback?
Brent: AB group repository
Planning for the week
matatk: Meeting for maturity model tomorrow
https://
matatk: reading all meeting details
Jen: We can meet with sustainibility group
JenStrickland: Thursday 3:30 to 4:45 will check
Lisa: Wiki page for all the issues and meetings will be helpful
matatk: sorry for not creating a wiki page. But I have HTML tool for scheduling meeting but it is not public for APA.
matatk: everything is recorded on github
matatk: We will have a page
matatk: Bringing use cases or issues
Tuesday: 15:00 to 16:00 meeting
Maturity model
matatk: Meeting before meeting Kavin
matatk: things to discuss in breakout - process for documentation
matatk: We have a documentation for all processes and groups
<Lisa> very hard for coga intergration
<Lisa> lovely to see u!
rssagent, end meeting
<Lisa> Coga uses community groups for light participation
Code of Ethics and Professional Conduct: https://
Antitrust Policy: https://
Presentation: https://
<jyasskin> matatk: <Presents>
matatk: Looking at changes we've made in APA and TAG to make the review process more accessible to spec authors.
matatk: Looking at what APA can do for you. Advice we can give. FAST. Want to hear from you.
matatk: Horizontal review is in several areas. Groups with expertise give spec authors input.
matatk: HR often happens too late.
matatk: In the official process, we often only hear long after a feature has shipped. We appreciate when feature authors flag us earlier.
matatk: The rough order you would do things is the TAG Screener, FAST, FAST Checklist, APA review. Several resources are behind this, including Accessibility User Requirements and Making Content Usable.
… When we do reviews we learn things, which we use to update our documents. Similar to how the TAG learns design principles from reviews.
… TAG screener (https://
… FAST checklist (https://
… User Requirements (https://
… Making Content Usable (https://
… APA's key deliverable is use cases. Best to look at these early on.
… We have other very technical people. CSS, ARIA. Talking to them later in the week about how to incorporate their knowledge.
… Explainers: https://
… Compute Pressure surprisingly has accessibility considerations: https://
… Solution isn't to add a "this is the accessibility stream", since that's very privacy-invasive. Instead, ensure users get to pin a stream.
… Considerations aren't in the API, but they're things to think about when using it.
Jaunita_Flessas: Essentially with the API, is there a way if they want to share information, e.g. they're using a screen reader that slows things down, could you flag to get rid of all content that would slow my experience down?
matatk: Coming back to that after the slides.
Fredrik: FAST encourages spec writers to provide information like the Compute Pressure Accessibility Considerations.
… Based on 2 pillars: user needs (very concrete, like person needing information about what a UI control is) functional needs (product perception, sensory and mental-load properties)
… Intersection of user needs and functional needs is where FAST provides advice.
… FAST advice was too abstract, and others have written things, so we're in a better situation, and we're rebooting FAST to make it more W3C-specific.
… We'd drifted into a too-academic place.
… Which actors are relevant? Spec, Author, UA, AT, User
… E.g. FAST describes how each actor interacts with alternative content
matatk: We're not necessarily talking about `alt` attribute. In our world [HTML], it's done that way, but it didn't have to be done that way and in another spec it might be done differently. Could have been decided that UAs display the alt text visibly. We're trying to be more concrete, but not totally prescriptive about how things should be done because that's up to spec authors.
Fredrik: On alt content, media queries are an area where alternative content may come into play profoundly, with alternative video/audio streams. Synchronization of streams.
… We want to support accessibility of products built on spec, authoring spec, and spec document itself.
matatk: Where's WCAG? Provides a baseline level of accessibility. Coverage of WCAG isn't universal, since we can only recommend things we know work. Some things are outside WCAG but FAST covers them. AURs can say "you need to be able to pin a window", but that applies to video streams, so can't be in WCAG.
… APA's goals: Available as early as possible. Think we can highlight use cases, and channel advice from other technical areas.
… Track specs' accessibility longitudinally. When we review the new version of a spec, we have historical entries for the spec. Was in wiki, now github.
… Improving horizontal review process. Suggestions + experiments
… Pain points? What advice do you want to get?
q&a
Jaunita_Flessas: If someone's using a screen reader or on 2G, can they share information to let an API reduce as much content as possible, to ensure the experience is fast?
matatk: I would say the issue of AT ... possible sometimes to guess that someone's using AT, but we design APIs to avoid revealing that for privacy reasons. Well-intentioned scenarios where people want to know. Let's make it faster so we don't need to worry about speed. But connection affects lots of people. There are other APIs for that, but we might also be able to look at Compute Pressure.
Jaunita_Flessas: If people elect to share, maybe?
bkardell: Pain points with HR process: frequently, there's so much work that goes into discussions, WGs trying their best to do things they're not experts in. E.g. CSS is really trying to do something they believe is the right thing for accessibility, but they're not experts.
… Could go 6 months-2 years, and then it goes to FPWD, gets wide review, and no, it's all off-base. But there's so much sunk cost, and we want to ship it. Maybe it's already shipping. Same is true of MathML WG that I'm chair of.
… Wide review come really late. Early in process, but late in practice. How do we find a way to get the liaisoning relationships working better? Fund lots more people?
<hdv> +1 to Brians point
kizu: +1 brian's comment. Often some proposals that later become specs come from outside WGs. Authors propose things. Issue in CSS might have been opened 10 years ago. Not noticed until it gets a formal proposal from Google, with an Intent. Big companies should do more to request accessibility review. But if we want review as early as possible, should be a way for proposers to request assistance. Process should be available for people outside
… spec authors.
… If we could flag topics that might require review, many proposals would benefit. Only goes to spec drafts or proposals from browsers, which might be too late.
matatk: Changes to TAG screener, which anyone can use, are designed to be really high-level and quick to fill in. Technical solution to social problem: it adds the label that flags the APA, if it's in a repo that has such a label.
… People in several groups, like CSS, will flag APA much earlier than HR would. We really appreciate it, but it's uneven, and it's a firehose. We're experimenting on turning up the firehose.
<Zakim> nigel, you wanted to ask about the accessibility of specification documents and automated W3C checkers
nigel: I'm from BBC, chair of Timed Text. Interested by the notion that accessibility HR might return information about the accessibility of the spec document itself. Tooling: when you publish to /TR, there's tooling to do some checks. Can't do everything, but have you identified gaps in tooling or things it would catch?
matatk: Good question and suggestion. Your specs are really good. We appreciate the effort people put in to write things accessibly for your community. No problem with lack of alt text. Diagrams that could themselves be accessible. Sometimes we report accessibility issues with specs. We don't come across them that often, and we often don't report them.
… Adopt a risk-based approach. Harm reduction, so we don't report everything. But general level is pretty good.
… Haven't seen much that tooling would catch.
cyns: Echoing Brian and Roman about getting things done earlier. See some work on that. Been a problem for 1M years, that accessibility review happens much too late. Want guidance in explainers to add it earlier. Other places like that? Reach the groups thinking about something, but accessibility is the furthest thing from their mind.
matatk: Should always be on the lookout for such places.
… People asking "how do we do it" after already wanting to.
… Explainers are good and fairly early. FAST is advice we distilled into our reviews that's about questions we get asked. But they're general requirements, and rebooted FAST will try to preempt things we see and have to raise during reviews.
<bkardell> note not everything has an explainer though... If we add a CSS property, it might or might not have one. If we add a attribute to MathML or a tag, it probably wouldn't
<Zakim> hdv, you wanted to talk about sometimes needing brainstorming more than review
hdv: In OpenUI, we work on building blocks for user interfaces. A lot of our work needs review, but also brainstorming. Things don't exist. Maybe they exist in ARIA, or not. We benefit from having someone in the room who's good at accessibility. Often have someone, but would be good to be able to call someone in who can say how you're wrong.
<bkardell> +1 hdv, that's kind of what I was saying with liasoning
<masonf> +1!
<Zakim> jyasskin, you wanted to ask about techniques for making authors _tend_ to produce accessible pages.
jyasskin: concerns about proposed futurs are often not that they can't be used accessibly, but more that authors _tend_ to use them inaccessibly.
jyasskin: we may need ways to @@@ not just what people are worried about.
matatk: Wanted to come back to Jaunita_Flessas. We have some really dedicated people in APA. All the people in APA are really dedicated, but there aren't enough of us. Send people please.
<bkardell> +1 please send people to all of the places
matatk: Know it's hard to get people to donate their time, but it does teach people a great deal, learning what everyone is working on. We'll support people, but we need help.
Fredrik: It's quite empowering.
matatk: Back to Jaunita_Flessas. I gave a facetious answer, but on ATs, it's sensitive and it comes up every so often.
matatk: Have you come up with places that would be way better if we could tell if someone were using a screen reader?
<hdv> jyasskin: a concern about that… if people can reveal some information they can be coerced to reveal that information
<hdv> astearns: or mislead
matatk: There are ways to guess. Jaunita_Flessas's point is really important, because the experience when you're using AT, is really degraded because code paths are less-tested.
<Zakim> nigel, you wanted to mention about selecting which info to expose to AT
nigel: On screen reader detection: Use case: you have video that's being watched by a blind person and a deaf person. You turn audio description on and subtitles, and there's a screen reader. Does the player expose the hard-of-hearing subtitles to the screen reader? Need a setting.
nigel: Giving the user a choice about what information the page should expose. Gives some information away, but it's a bit different.
matatk: Al Gilman said "author proposes, user disposes". If your page is sending out the information, but their AT can filter it, it can do that without revealing it's running. Aria notifications API can work in that way. If you're receiving it, great. If not, page doesn't find out.
matatk: Next steps: Join us. Get in touch: we don't bite much. We're adding more ways to get into our repository. Don't be afraid to ask even if you don't see a template.
… Thank you for coming. Impressed at how many people are here.