Meeting minutes
<jamesn> https://
PR review
Matt_King: issue #2505
<Github1> https://
jongund: this was also happening in other places, a CSS selector needed to be changed, no big deal
<Github1> https://
Matt_King: PR #2509 fixes this
<Github1> https://
Matt_King: alex, i know you want to stabilize things, but this should be pretty simple to add?
Matt_King: looks like no preview was generated, Alex do you know why?
Alex: I'll look into with Howard, not exactly sure what the issue might be
Matt_King: should this go into the PR 2417 branch?
Alex: Yes
jongund: there's no huge changes in my PR, just the CSS and an outdated link. since i was in there, I updated that
Matt_King: wondering how we want to review this PR, maybe people could look at the CSS?
jongund: i only took out two characters, up to you
jongund: the selector used to be any anchor in a <p> element, now it's any anchor in the <main> element
Matt_King: this CSS ONLY applies to the landmark example?
jamesn: yes
Matt_King: oh this shouldn't need any review then really
jongund: there was a stylesheet that was referenced twice, I removed the duplicate
<jongund_> MK: The other PR this week is ..., I was confused by the commits were from some months ago
<jongund_> MK: PR related to dialogs
<jongund_> MK: PR #2512
<Github1> https://
<Matt_King> PR 2512: https://
<jongund_> JN: I accidentally added some content, so I had to remove it, so it is really only one commit
<jongund_> JN: The second commit is the one to pay attention too
<jongund_> MK: This is a content issue, and we agreed to make some changes, so I am thinking about timing
<jongund_> MK: We would get better tracking if we wait until the new content tree
<jongund_> MK: JN can you wait a few weeks?
<jongund_> JN: Sure
<jongund_> MK: Thanks, that will simplify things
Matt_King: there's a warning class, a note class... role references, property references, that are unlinked. HTML-mapping...
Matt_King: the first two are motly used for styling, the others are ARIA specific. Alex, do you know what happens to the warning, note classes in production?
Alex: Note styling is applied, but I'm not sure about warning
Matt_King: Note is definitely used in the patterns (like the keyboard section, properties/states section). in THIS PR, the note is titled, so I'm not sure what or why it is
jamesn: respec will translate the title into the heading for the note
Matt_King: it seems like respec gets the heading level wrong a lot
jamesn: it shouldn't, though
jamesn: we don't use <title> in ARIA right now, but I have an issue open to make better guesses based on the previous heading
jamesn: putting a specific title on it is probably a good idea
Matt_King: Alex, where do you think this should go? I've seen something like this in WCAG's guidelines. makes me think there's something in the WAI templates
Matt_King: could be a problem in the templates, since the heading and note get separated
Matt_King: as if the section where the note actually is, doesn't have a heading
Matt_King: i noticed it in the Understanding section of WCAG guidelines
Matt_King: should this be in our CSS? WAI's? or we lean on the WAI templates? do we want to add support for <title>?
jamesn: If there's a different way you want to do notes, go for it. I'm happy with anything the group likes. The WCAG Understanding stuff is generated by respec
jamesn: I could be wrong though (about respec generating those). WCAG itself IS respec
Matt_King: one benefit to doing it how respec does it is that editors for multiple things don't have to relearn as much
Alex: if we're not using loopback, it might be hard for someone to understand the importance of the <title> attr. sticking to HTML markup for all notes would be my recommendation, no need for JS transformation
Alex: About the template, we use its styling and there's some we cant ge working exactly correctly just yet
Matt_King: so is there transformation on notes in the patterns right now?
Alex: Yes but it won't be there on the new branch
Matt_King: should we replace all "Note" classes with something else? Or?
Alex: I would advocate for that but am open to other ideas
jongund_: is this discussion better suited for the editor's meeting?
Matt_King: anyone can use this guidance if they're writing content, but that's a good question
Matt_King: Alex, we should look at how complicated it'd be to continue using that class
Matt_King: i'll make a note (heh) to myself to find the correct issue to solve this in
Matt_King: Alex, I might ask for your guidance or rough guess on where and how much would be needed
Alex: Sounds good
Matt_King: Decisions: we're waiting on 2512, and I'm merging Jon's PR
QA plan for updated Netlify APG site
Matt_King: we're changing every pattern and practices page, so I want a QA plan where we have at least 2 people spending a few minutes looking at every page on the site
Matt_King: dividing this up, I'd think it'll take 4 people an hour each to check every page
<jongund_> I can help
Matt_King: this is just a spot check. we have a bot to check links, and content is the same. Changes are things like moving chunks around.
Matt_King: main thing is to make sure we haven't regressed the appearance or broken anything
Matt_King: i.e. compare production to preview and make sure things are the same
Matt_King: we don't have the preview yet, but i am looking for reviewers on 2417 KNOWING that this should be a bigger(ish) one that'll take about an hour
HelenZhou: I'll volunteer too
Matt_King: Alex, do you have an estimate for when the preview link will be ready?
Alex: I still need to stabilize that branch, and that should be close by end of the week. THEN we can start on the WAI ARIA-practices repo work. no estimate yet
Matt_King: so maybe not next week, the following week?
Alex: Could be a good target
Matt_King: I'd love to get the review done in a week, once it's ready
Matt_King: I'll ask again next week
Matt_King: Alex, any blockers on stabilizing the branch?
Alex: No, but getting through two PRs including the link checker
Alex: I could use feedback on #2481
<Github1> https://
Matt_King: got it
Matt_King: I'll raise the issue about the classes (sorry to make more work for stabilization). Any other issues we need to discuss about stabilization?
Alex: We discussed generating patterns/practices files. Not currently urgent or anything, but on my mind as a future requirement
Matt_King: we could punt that til after we land this immediate work
Matt_King: I don't think we're directly linking to those anywhere besides navigation, so it's not as urgent right?
Alex: That's true
New Issues
Matt_King: there are four in our agenda today
Pattern for browsable 'locked' or 'answered' quiz/test/exam question? #2508
<Github1> https://
github: https://
Matt_King: we got responses from Brennan.
MarkMcCarthy: [reading Brennan's response]
jongund_: sometimes, if "you answered X" type of statement goes after a question, an AT user has to get to that AFTER getting through disabled controls, so putting it before the quesdtion could help
jamesn: adding that (before the question) AND -readonly would be perfect
Matt_King: ultimately, I think that's good feedback.
jongund_: should be it be signified in a landmark or heading? other than plain text, anyway?
Matt_King: semantically, if the questions and answers are list items or paragraphs, or otherwise are supported by a heading structure, I wouldn't recommend it
jongund_: what about a region with an accname of "Question Result" or something similar?
Matt_King: if there's one question per page, and already a few regions, sure. if there's 40 on a page, and it's imperative to get to the nav region, that could clog things up
Matt_King: I'm not sure what could be widely reusable for a pattern here. For inclusive tests/quizzes, absolutely. broadly speaking, though, i'm not sure.
jamesn: there's definitely a use case, but every test designer may choose soemthing different
jongund_: a dialog box could also be a good way to express feedback/answers to questions
Matt_King: that works well for us here at Meta
jamesn: this is a perfect case for readonly. it's readable by everyone, and not disabled.
Matt_King: why?
jamesn: the disabled attribute makes it unreadable (visually) - they don't pass contrast. it effectively says "this isn't relevant"
jamesn: the fact that HTML doesn't support readonly... it's technicalities, and IMO should be updated
jamesn: i've worked on several apps where disabled and readonly both should and can be used, and they mean different things
jamesn: we allow aria-disabled and aria-readonly on many different things, though it may or may not be supported by all user agents
Matt_King: So, our feedback is that aria-disabled is the most interoperable solution, moreso than HTML disabled.
jamesn: Yes, but then you have to make it non-operable in different ways (could even be a good use of a <div> vs. <input>)
jamesn: or use <disabled> and override the CSS to make it perceivable
Matt_King: just depends on how they want to build it
Wrap-up
Matt_King: We'll see you all next week!