<jeanne> trackbot, start meeting

<trackbot> Meeting: Silver Community Group Teleconference

<trackbot> Date: 15 October 2019

<Lauriat> Scribe: Lauriat

Alt text update

<Cyborg> https://docs.google.com/document/d/12MbzzePklkoITusRM7gQyKUHtx6Ygsnd8RYQbIZ-qhM/edit#heading=h.8j6pwbsnl608

Cyborg: We have some things in email that we should put in the document itself.
... We've gone through defining user needs, but we haven't gone through everyone's comments (a lot left).
... We've started looking at tests, but we haven't put that in the document yet.
... Where does 1.1 fall short, where are the grey areas (pass vs. fail)? What about quality of alt text and better measurements of alt text quality?
... Are there better tests for how usable alt text is on common technology?

Jenn: We've gone through those areas, looking forward to getting into the tests.
... How descriptive is the alt text, that can have a real impact on the users. Having a validated test for that is an interesting thing to explore.

Cyborg: In cognitive needs, emotional content in alt text, this also gets into quality of alt text.

CharlesHall: Whether or not speech cadence or pauses or special characters are mentioned in that quality of text?

Jenn: I don't know specifically. I don't think they are, but I think they're important.

Cyborg: +1

<Zakim> bbailey, you wanted to ask about descriptive identification vs textual equivalent

bbailey: 1.1.1, the divide is between descriptive identification vs. textual equivalent, and I don't really see that in here.

Jenn: Happy to explore being more definitive around that. Do you think we should be more distinctive around where you should do one vs. the other?

bbailey: A lot of times, people will go overboard with long descriptions when shorter is more helpful for the user.

Jenn: Putting notes on the document on that, thanks.

<Zakim> janina, you wanted to shorter is better, especially for content that will be revisited time and again

janina: Useful to note that we tried to qualify this in order to avoid really long alt text. Some examples ended up well over 100 words, where maybe anything over 50 words is not helpful alt text. Especially content you'll come across over and over again.

<jeanne> jhttps://www.w3.org/WAI/tutorials/images/decision-tree/

<jeanne> https://dev.w3.org/html5/alt-techniques/developer.html

jeanne: I added a couple of links, some of the documents janina referred to that you might find helpful.

Jenn: Great, thank you! Maybe we can review these in our meetings from here.

jeanne: I think the part where you're trying to work on the definitions of what is alt text gets into a tricky place. There's a lot of work done there that you're probably better off reusing. It's really tricky and has gone on over the last 10 - 20 years and I would caution against trying to change that.
... Unless there's a specific user need that hasn't been addressed before.

Cyborg: Emotional content and maybe a greater focus of use of alt text. Not so much adding or changing the definition, but what tests or methods could better achieve what is intended.
... Are there ways of writing alt text that could better meet intents?

Jenn: I agree that we take each of those test cases as baseline. I'd very much like to look at what's already done.

jeanne: You've done a lot of work and this looks really good! Very eager to see where you continue to go with it.

Cyborg: Clarifying: is there a better way to set up the way to evaluate that?

(Scribe fail)

<CharlesHall> there is likely a programmatic way to interogate redundancies in alt value and surrounding context.

janina: I don't want to nitpick on this, as I think it's a good exercise to consider how to write good alt text. How do we distinguish between writing for cognitive related needs vs. blind / low vision needs? Can we write in order to meet both sets of needs?

Cyborg: I expect so. Some people would have both needs as well.

<Cyborg> literal vs implied or inferred by an image

janina: Had someone argue a while back for removing alt text and removing server side.

<jeanne> Conformance Example of Alternative Text <- https://docs.google.com/document/d/1IK83Gfxz01zFWgNtaCWCL0LeBqhu9DudyWp_IwovWc0/edit#heading=h.gbpelxi718we

janina: The argument: alt text confused their users.

<Jenn> +1 Thank you all very much for the feedback.

Content writing process

<Rachael> scribe: Rachael

lauriat: I want to do a retrospective on how we are writing content. Some though have learned more than others.
... I'd like to take time to discuss what has gone well, what needs to be improved, and think about what we can do differently. I want this to be a structured conversation to fit it into half an hour

<Lauriat> https://docs.google.com/document/d/1hHzlnmQQwZb0za6Zt73pYB5-EDntrsdvkjB3NxkGgd4/edit

lauriat: more of a brainstorming activity. Keep descriptions and anectdotes minimal unless something doesn't make sense without it.

The document linked above is to track this.

scribe: more to follow along. All should have access. Focus on what went well to start. So what went well?
... sounds like we have a good set of user needs.

Chuck: The teamwork went well. We started as individuals but we came together as teams. That improved quality. I realized how silod I was being and that was limiting.

<Zakim> janina, you wanted to ask how we distinguish alt for coga vs alt for screen reader users?

Lauriat: What else went well? Tooling? Content? Structure?

Cyborg: Having the user need focused first. Drawing out user needs and delving deeper before moving forward. I see large benefit coming out of that. I've worked on 3 documents on cognitive and low vision. What get emphasis differs. There has been a range of room for depth of exploration that I think shifts conversation

Lauriat: I agree
... From my perspective, having the work happen in parrallel instead of just in these calls has been working fairly well. In calls we just review where we are and what we are doing next.
... Please add to IRC if something occurs to you.
... for what didn't go well or could go better. One person wrote: Mismatch between content development and migration map. Can who wrote that discuss?

Cyborg: The migration map was breaking up the SC and putting some together. That was done in a more meta way. In the work on the individual piece of guidance, when we try to implement that it doesn't always work. We struggle with it in contrast and in alt text. In alt text, it is a relatively minor one. With contrast, it may be helpful to have a larger meta around visual readability and presentation...

and then have contrast underneath that. The way that visual readability was divided didn't quite match that.

Chuck: My concern is that the scope increased dramatically in color contrast.
... under the current time pressure, we've run into stress and difficulties in completing.

<Cyborg> +1 for what Chuck is saying

Chuck: definitely could have gone better

Lauriat: The email traffic about that is part of why we want to have this conversation. To better understand what to shift

Cyborg: I would just add to what Chuch said that contrast became essentially a new piece of guidance. There is a huge time difference between migration vs. new guidance. Worlds apart.

Lauriat: Next in the doc "Tracking work in progress through GitHub or other available method" Is this a way to improve it?

CharlesHall: This is a suggestion about how to track who is working on what and tracking

Lauriat: Next "Who has the pen” very ambiguous"

Bruce: I find simultaneous editing difficult. Google Docs makes it almost too easy to make changes.

Janina: +1 to that

Lauriat: Is there something else that hasn't gone well or we could do better?

Andy: Pretty big difference between new work and migration. The time constraints can be challenging as some items are still being researched. It brings up a question about migration vs newer methods. We need to allocate more time to new content.

Lauriat: There were two things that were related. I captured it as "Difficulty ramping up on migration project (related to direct migration vs. new)"
... did that capture what you are trying to say?

Andy: Yes. Its largely because migration is more straightforward. Adding migration and new content at the same time has led us down paths that will lead to great standards in the future but have added layers of complexity

Lauriat: Agreed. I was expecting the migration would prove more complicated than new content. New content has different challenges.

<bbailey> +1

Chuck: Not intending to throw someone under the bus - sorry. The date of November has caused some stress, trying to meet that date when I thought we had more latitude. It may be worth revisiting how that mistake happened.

Lauriat: +1 to that.

Cyborg: Lack of clarity around what the first draft is trying to prove. It creates a tension between getting a single part done well and a broader. We understand it is iterative but we don't want to invite feedback on an inaccurate/erroneous part that could negatively impact the future of silver.
... clear guidance on what the first draft will include would be helpful

<Lauriat> "Lack of clarity for what the draft needs to do and what level of quality we need to include"

Lauriat: rephrased as above

<Cyborg> +1

Lauriat: What do we change moving forward. These may be thigns we do individually or things Jeanne and I go off and do. There are a few things already noted.

<Lauriat> 1. Place markers in document where public comment / conversation is needed

Charles: This is to note where we are inviting comment or conversation. This comes from a conversation Cyborg and I just had about the dilmena of needing a definition of user need. We need to mark these in the document itself.

Lauriat: We can have a section at the top of the document that points to known actions needed. It doesnt' have to be comprehensive. If there is a thing that needs to happen, note it.

Cyborg: I am fine with github but not everyone is comfortable with github.
... I added a third point, it would be helpful to identify places where we are still working but also note places where we want to have discussion and feedback. Areas that need more work is one piece. Where we want to expand discussion is different.

Lauriat: How would you track those needs?

Cyborg: We could open up brainstorming solutions. We could indicate specific places where we want feedback.

Lauriat: Discussing how to manage that may be a good conversation with the other task forces. To include them and their reach of contacts. Expand in other directions

Cyborg: It looks like we are moving from contrast alone to other visual components.

Lauriat: We did expect that when working in depth, some groupings wouldn't work. Rather than contort the structure, I encourage people to state, this grouping doesn't work but this does and suggest a new grouping.
... similarly, you should identify a grouping that doesnt' work even if you don't know how it should.

<Cyborg> Thanks to Shawn regarding regrouping migration map as we work on specific guidance

Makoto: It would be helpful to have graphical examples such as screenshots in our documnents. It can be difficult to understand the documents. Graphical examples are powerful and helpful, particularly if we want more international involvement and feedback.

Lauriat: Big +1 to that.

<Jenn> +1

Andy: Add to what Cyborg was saying. I've been working on an email set to make it more succinct. Using a database with tags to handle the information. Just to play on that, some of these have so much crossover. We are not indendent machines with independent parts. Everything in humans overlaps.
... tests and methods may overlap areas.

<CharlesHall> hard stop. have to drop. :(

Andy: something to think about (how things overlap) as we go forward. How are we going to incorporate those things.

Lauriat: Somethign we've talked about with regards to information architecture but we don't have that worked out. One last thing in document.
... when are we ready?
... I think Jeanne and I should work with the chairs to define exactly what the draft is for. Also revisit deadline.
... learned alot.

<Lauriat> trackbot, make minutes

<trackbot> Sorry, Lauriat, I don't understand 'trackbot, make minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<Lauriat> trackbot, end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/rendering server/removing server/
Succeeded: s/divide is between description vs. text alternative/divide is between descriptive identification vs. textual equivalent/
Default Present: jeanne, Rachael, Lauriat, Chuck, janina, Makoto, Cyborg, CharlesHall, johnkirkwood, bbailey, KimD
Present: jeanne Rachael Lauriat Chuck janina Makoto Cyborg CharlesHall johnkirkwood bbailey KimD
Found Scribe: Lauriat
Inferring ScribeNick: Lauriat
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Scribes: Lauriat, Rachael
ScribeNicks: Lauriat, Rachael
Found Date: 15 Oct 2019
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)