Meeting minutes
<Laura_Carlson> Me too "Sorry, Insufficient Access Privileges" error for
<Laura_Carlson> https://
<julierawe> date: 06aug2024
<Laura_Carlson> I'm still getting the "Sorry, Insufficient Access Privileges" error for
<Laura_Carlson> https://
<Laura_Carlson> Thank you!
<julierawe> https://
<julierawe> https://
<julierawe> julierawe Let's either define 'inline explanation' or replace with more specific wording
<julierawe> Laura_Carlson Inline means in the same sentence
<julierawe> kirkwood In the same sentence, you don't have to scroll
<julierawe> kirkwood What about rollover explanation—so you don't have to move arond
<julierawe> Julie will email directions on how to do the card sort exercise. Deadline is August 15
<JohnRochford> "An inline element is an HTML element that does not start on a new line and takes up only the necessary width"
Julie: I heard John Kirkwood say that I think there should be a roll-over definition / explanation.
Julie: The third technique is to provide a glossary and we also talk about tool tips and pop-ups there.
John: Yes, I thought we might want to mention it in the inline section.
Julie: I think we should make the different techniques sound distinctly different - that is my sense. What are your thoughts?
JohnR: I pasted in a definition of an inline element
<Laura_Carlson> Inline elements
<Laura_Carlson> http://
<Laura_Carlson> Block-level elements: http://
<Jan> Julie: Should we move the roll-over from item 3 to item 1
<Jan> JohnR: A pop-up would be part of the inline defintion.
<Jan> MikeB: I agree with JohnR
<Jan> Julie: So, we combine role #3 into role #1
<Jan> Len: If we start to move away from just text, it becomes a slippery slope and might be difficult to know what to include.
<Jan> JohnK: I agree - on mobile devices, tool-tips and pop-ups become difficult on mobile because there is no roll-over function.
<Jan> JohnR: To JohnK's point, they don't work now, but maybe they will work later.
<Jan> Julie: We could provide 2 examples - brackets at the end of the sentence or a pop-up.
<Jan> Len: To me, inline text is truly in the sentence (pure writing). Other tools are different techniques - as soon as I think about code, I think it's a different method.
<Jan> JohnR: I think most people who are writing their content are using code.
<Jan> Julie: In the content management software we use in my job, we have a toolbox that allows us to add a toolbox without doing any coding - I just select it from a menu, so I don't know if that is helpful.
<Jan> Len: If I write a plain paragraph and I decide if I want to bold or italicize. I still think, at its simplest form, inline is just typing in pure text. Anything on the keyboard that is already available would fit the definition of fitting it into a sentence.
<Jan> Julie: Makoto mentioned last week that in Japanese, you would not use brackets.
<Jan> Makoto: I would prefer that the functions be in different techniques to make it easier for people to find them.
<Jan> Julie: One of the things that we're including in this technique is that you could use different styling. If we were to use Len's exact definition, then the styling would need to be a different technique.
<Jan> JohnR: That sounds good to me, but I was also thinking about how assistive technology can add symbols, definitions, etc. above the text - I wonder if we should be telling authors that whatever they choose should not interfere with assistive technologies. For example, if an author decides above the sentences, they might put tips, etc., that might
<Jan> overlap with assistive technologies.
<Jan> Julie: For any technique, we want to make sure that it does not interfere with assistive technology.
<Jan> JohnR: I think it would apply to any technique, but particularly inline.
<Jan> Julie: Is that a reason to separate inline tooltips from inline explanations that don't have a tooltip.
<Jan> JohnR: My concern is that if we go down this road, there's no way for us to know all of the possible implementation methods, especially in the future.
<kirkwood> when googling implementation first thing that came up “
<kirkwood> In this video, you will learn how to add a pop-up definition to words or phrases in your text boxes using our inline explanation feature.”
<Jan> Len: I agree with that John. We have one content management system (CMS) and we've just started looking at voice UIs and as we think about that, we're going back through how a CMS works with various copy and we are disentangling pop-ups and tooltips triggers to work with other CMS', but that's too big of a list for explaining all of the details - I
<Jan> think we should put it on the author to figure that out because they know their audience.
<Jan> Julie: Are you still thinking that pop-up is a separate technique?
<Jan> JohnK: I just want to think about it from a developer's perspective and when you look into it, it will give you multiple techniques for how to put things like pop-ups into the text. It seems to be a moving target.
<kirkwood> +1 to Jan
<julierawe> Jan By having more categories and buckets, it makes it more complex to consumer the content
<julierawe> Jan When you have fewer buckets, it can make it easier for people to understand the strucutre
<kirkwood> ack
<Jan> Julie: Any other thoughts?
<Jan> Julie: Let's vote on combining the pop-up into the inline explanation technique:
<Jan> Julie: If you want to combine the pop-up technique to make it a part of the inline explanation technique, vote +1, if you are opposed, please vote -1 would be to keep them separate and a 0 would be not sure, or need more information.
<Jan> JohnR: I am not sure why we are voting on this.
<Jan> Julie: It's just so we can move forward. The question is - as we build our techniques, we need to know if we should have the pop-up technique added to the inline technique or not. At some point, we need to decide how we're handling this.
<Jan> JohnK: Are pop-ups covered somewhere else?
<Jan> Julie: There's a technique that uses the term glossary and does not specifically mention pop-up
<Jan> Julie: #1 is provide an inline explanation; #2 is block of text; #3 is provide a glossary and one of the techniques was using a tooltip. The question is whether 3 is an example of 1 because a pop-up would be inline with the text.
<Jan> Julie: With Len's explanation, he was making the case that a pop-up is a different technique.
<Jan> JohnK: With that explanation, I think they should be separate.
<Jan> Julie: The question is, should you use only text with what you can type from a keyboard, or should you also use other techniques that provide information inline with techniques such as tool-tips, pop-ups, etc.
<kirkwood> +1 to John
<Jan> JohnR: I am thinking about how fundamentally, we are focused on what authors can do and Len talked about different technologies that help authors. On the other hand, we have what users experience. Traditionally the W3C have focused on what users experience and have left open what authors can do to create that experience. I don't know why we would
<Jan> deviate from that. Why are we focused on what authors should do? I think we should be talking about the user experience exclusively.
<Makoto> -1, I prefer to keep them separate
<LenB> -1
<kirkwood> -1, I prefer to keep them separate
<Jan> Julie: The vote is to combine pop-up as part of providing an inline explanation - an example. If you are in favor, vote +1, if you are not in favor, vote -1
<Jan> Laura: I would vote -1 because it won't work in Japanese.
<Jan> Makota: I think people who would check the techniques would be authors, so I would prefer to keep them separate so that they can find the techniques more easily.
<Frankie> 0, not sure this decision needs to be made today
<JohnRochford> 0
<Laura_Carlson> 0
<Jan> +1 I still think that putting these things into multiple buckets will actually make it more difficult for authors to find what they need.
<Makoto> I think language doesn't matter on this vote.
<Laura_Carlson> Thanks, Makoto
<julierawe> julierawe I will look at WCAG 2.2 to see if any of those outcomes can help guide us on whether to have bigger or smaller buckets
<julierawe> Jan I think it gets really complex when you use the same terminology across multiple buckets
<kirkwood> yes leave it flexible
<Jan> Julie: I will take a look at WCAG 2.2 that might help guide our thinking on buckets and we will talk about it next week. I will also email the card sort activity.
<Jan> MikeB: I would like to discuss a technique for using alternative language - not be so prescriptive
<Jan> Julie: Maybe what we need is a method about replacing with literal language.
<Jan> I have to hop to another meeting. Thanks everyone!
<Makoto> Thanks Jan for scribing!
<julierawe> julierawe Mike agreed to draft a technique about replacing non-literal language with literal language so there is no implied meaning that needs to be explained.
<julierawe> julierawe We'll start next week's discussion by reviewing that new technique.