<Rachael> scribe+

<scribe> Scribe: laura

RM: Likely will be a light meeting. Working session.

Introductions and New Topics

RM: Any new topics?
... Any new members?

Working Session - Alternative Text Outcome https://docs.google.com/document/d/1wkQ8ZKiRnNnax9ENaDXfQhl6kh-iYlXx7gMEhKMTQBU/edit#heading=h.cu8l0ohk9n2q

RM: (none)
... mainly working in the document.

<Rachael> Wrtiing testable outcomes: https://docs.google.com/document/d/1sugAtqie_x1XqHDZo1Im7ftDNllWeRV_ty4PULeoTV0/edit#heading=h.yat8qtriwxm8

RM: last week we went thought the first step.
... ready to move to step 2, creating a rough outline.
... will share screen.
... With a new (or updated) list of examples, write the outcome in such a way that the categorization of all examples becomes clear. Passing examples must pass for some reason described in the outcome, similarly for failure examples. If some kind of level exists in the categorization, write an outcome for each level and avoid overlap between them.
... With a new (or updated) list of examples, write the outcome in such a way that the categorization of all examples becomes clear. Passing examples must pass for some reason described in the outcome, similarly for failure examples. If some kind of level exists in the categorization, write an outcome for each level and avoid overlap between them.
... With a new (or updated) list of examples, write the outcome in such a way that the categorization of all examples becomes clear. Passing examples must pass for some reason described in the outcome, similarly for failure examples. If some kind of level exists in the categorization, write an outcome for each level and avoid overlap between them.
... Avoid discussions on readability, complexity or definitions. The focus at this stage should be on ensuring all the possible edge cases are described in the text of the outcome. Don’t feel compelled to write the outcome down in a single sentence.
... Outcomes do not need to be short. If more words are needed for a proper description, use them. In other words, WCAG 3 Outcomes do not need to look like WCAG 2 Success Criteria.

<Rachael> https://docs.google.com/document/d/1wkQ8ZKiRnNnax9ENaDXfQhl6kh-iYlXx7gMEhKMTQBU/edit#heading=h.n07i3nmvznhy

<Rachael> Scratchpad: Image alternative: Images have text alternatives

<julierawe> For ease of understanding, could the outcome be "Images and other non-text content have text alternatives"?

RM: we need to draft text.
... moving from explority to developing.

<Zakim> alastairc, you wanted to comment on the scope of 'non-text content'

ac: nontext content seems wide.
... or maybe it is.
... we need to differentiate.

<Zakim> kevin, you wanted to ask if not using 'images' will end up with us using much more confusing language

kevin: may be tying ourselves in knots if we don't use the term "images".

<julierawe> +1 to kevin's comments

<alastairc> Top definition for 'image' = "a visual representation of something", which seems ok...

<mbgower> rrsagent make minutes

<kirkwood> can we simply say “non text content”

<Rachael> Kevin's suggested text: Text alternatives are provided for visual content

<Zakim> jeanne, you wanted to say that we want to keep the outcome tightly focused on the solution

<ljoakley1> jeanne +1

<Makoto> +1 to Jeanne it is good to narrow the scope.

<Zakim> Jennie, you wanted to ask about animated images

<kirkwood> novel idea: file type?

<bruce_bailey> +1 to narrow the scope

<mbgower> static image < microanimations < animations < videos

<Zakim> bruce_bailey, you wanted to suggest NOT addressing edge cases, at least for now

<kevin> https://docs.google.com/document/d/1wkQ8ZKiRnNnax9ENaDXfQhl6kh-iYlXx7gMEhKMTQBU/edit?pli=1

<Zakim> mbgower, you wanted to say there is a fairly obvious progression from static images to microanimations to animations to videos, relatively easy to differeniate, which all have

<Zakim> alastairc, you wanted to comment on file types, not at the outcome level, but could at the method level.

<bruce_bailey> +1 that file type is less useful than one might first assume

<scotto> +1 to dan's comment. file type is likely not the way to go. more like what mike was saying. e.g., is it static, vs animated/dynamic, or a graphical / traversable document (e.g., svg)

<bruce_bailey> +1 to lori for static

<Zakim> mbgower, you wanted to say that static/non-static is the effect division

<alastairc> dj - an icon which quivers, or changes colour as you scroll down is a very minor (micro) animation.

<Zakim> dj, you wanted to talk about conditionally nonstatic images

<ljoakley1> 1+

<dan_bjorge> +1 to DJ - I think if there's a distinction, it's more about complexity than animation. For text alternative purposes, I think a complex graph is more similar to a complex video than an animated smiley face is to a complex video.

<Zakim> mbgower, you wanted to say that if it is operable, it is a function

<Rachael> +1 to static operable = easy

<kevin> +1

<Zakim> Rachael, you wanted to move us forward

<Rachael> straw poll: a) Text alternatives are provided for static, non-operable images b) Text alternatives are provided for simple images

<alastairc> a, as it's easier to define

<mbgower> both a and b

a

<dj> would b exclude graphs?

<ljoakley1> a

<kevin> a

<bruce_bailey> b

<jeanne> b, but can live with a

<Rachael> b

<graham> Other: why do we want to write different rules depending on complexity, should we not try and write a singular rule but have multiple examples of how to write good alt text. I think trying to define a "boundary" on what is simple vs complex, animated vs gif vs static is a nightmare.

<dj> other: text alternatives are provided for non-operable images

<alastairc> Graham - where do you draw the line between images, animation and multimedia?

<dj> graham++

<alastairc> as the solutions are very different

<dj> alastairc: when there are multiple media

<alastairc> dj - ok, images / animation / video

<dj> i'd say images / video

<Makoto> +1 to graham. I like the John's idea of file type: gif, jpg, png, svg etc.

<dan_bjorge> +1 to "Text alternatives are provided for non-operable images", agree with graham/alastair that it's too hard to make a testable boundary for "simple"

<Zakim> bruce_bailey, you wanted to argue for (b) -- if question simple or not , then move on (for now)

<Jennie> +1 to DJ's suggestion: non-operable images

+1 to dj

<dan_bjorge> +1 to "non-operable images"

<Zakim> alastairc, you wanted to argue against myself

<scotto> appreciate the distinction. not sold on the term 'non-operable' images. since i would never describe an image itself as "operable"

<scotto> but aside from that terminology, agree with dj

Nayan: I'm new and live in los angles.

Kimberly: I'm newish. I work for SAP.

John Tloes: Work at Georgia Tech.

<graham> warm welcome to Nayam, Kimberly and John!

<dj> orientation was also recorded

<Zakim> jeanne, you wanted to say I like Mike Gower's idea of the importance of the image -- I had to think about it, but I think that is a creative solution that could be more useful.

<Zakim> Rachael, you wanted to build on Mike's comment

<Zakim> mbgower, you wanted to say I just put in some information on rethinking this whole space

<bruce_bailey> love the LoC example of alternative text being complicated

<Zakim> dj, you wanted to say images of text alt text: isn't WCAG 3 a mix of UAAG and WCAG 2.x?

<Zakim> bruce_bailey, you wanted to pile on Rachael comment that end-users have different expectations.

<Zakim> Rachael, you wanted to respond to DJ

<Zakim> dj, you wanted to talk about images with roles (hr)

<Zakim> Rachael, you wanted to say next step

<scotto> this topic reminds me i raised an issue to ARIA to allow people to identify images that are "decorative" but would still be useful to provide alt text for - https://github.com/w3c/aria/issues/1746

<bruce_bailey> agree if we don't try to address legacy use of alt as substitute for HR and hack like gif spacer shims -- requirements are easier

<scotto> the term 'decorative' is probably wrong here... since decorative is so steeped in "ignore this" rather than "this has information that one might want to know"

<Rachael> Next step poll: 1) create definitions 2) pick a direction and try it

<dj> 2

<mbgower> 2

<jeanne> 2

<scotto> 2

<alastairc> 2

<graham> 2

<Rachael> 2

<bruce_bailey> 2

<ljoakley1> 2

<Makoto> 2

<kevin> 2

2

<jtoles> 2

<Jennie> 2

<bruce_bailey> +1 to scott's point about about "decorative" being abused

<Rachael> draft Straw Poll: 1) Operable/NonOperable 2) Static/Non-Static 3) Easy for the author 4) Importance of Task 5) Image/Video/HR 6) Just Images and no distinction

<jtoles> informative vs. decorative?

<ljoakley1> 2

<alastairc> 1 + 2 (non-operable static)

<jeanne> 4 - although that will potentially take a lot more exploration, but better long term usefulness.

<Rachael> draft Straw Poll: 1) Operable/NonOperable 2) Static/Non-Static 3) Ease for the author 4) Importance of Task 5) Image/Video/HR 6) Just Images and no distinction 7) Informative/Decorative

<dan_bjorge> 1

<bruce_bailey> 4 then 3

1

<dj> 5, 6, 7

<kirkwood> 5

<scotto> 3, 4

<mbgower> I like combining 1 and 2, but 1 on its own might also be useful. I think we can build from there with some of these others

<kevin> 6, 4, 1

<jtoles> 1, 5, or 7 need a better term than operative/non-operative

<scotto> i don't understand the diff between 1 and 2

<graham> i honestly don't get what I am voting for here, all are applicable in some sense, are these "headings", "things we want to tackle first"? I may have missed something key

<bruce_bailey> note, by "easy for the author" -- I mean "easy to know what the author should be doing"

<Zakim> kevin, you wanted to ask if the examples are Methods?

<Zakim> alastairc, you wanted to suggest "Text alternatives are provided for non-decorative, static images; unless the image is part of an operable control and covered by the control name"

As Eric Bailey wrote, Your Image Is Probably Not Decorative. https://www.smashingmagazine.com/2021/06/img-alt-attribute-alternate-description-decorative/

<kevin> +1 to Alastair's suggestion as a starting point to get moving

<bruce_bailey> +1 that decorative images are almost not a thing

+1 to Graham

<kirkwood> +1 to Graham

+q

<bruce_bailey> but disagree that more alt is usually better

<kevin> https://www.w3.org/WAI/tutorials/images/decision-tree/

-q

<Zakim> jeanne, you wanted to talk about decision tree

<Makoto> Text alternative for images is one of the frequently discovered issues. The decision tree can be a good solution for different types of images.

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

<Zakim> alastairc, you wanted to comment on technology breadth, and they may have different ways of included decorative images (which actually are decorative)

As Lennie Watson has said, “good alt text can conjure up wonderfully stimulating mental images.” https://tink.uk/text-descriptions-emotion-rich-images/

<Rachael> akc Ben_Tillyer

<alastairc> Think about other tech, including PDF, VR, mobile etc, let's not make it specific to HTML

<bruce_bailey> WebAIM has a nuanced article including alt="" https://webaim.org/techniques/alttext/

<bruce_bailey> Agree with Ben that Freedom Scientific is evidence that stock photos fair to be treated as pure decoration.

<Zakim> mbgower, you wanted to say that it is likely to cause noise

<jeanne> A 2018 Silver document on a heuristic approach to Images Need Alternative <- https://docs.google.com/document/d/1IK83Gfxz01zFWgNtaCWCL0LeBqhu9DudyWp_IwovWc0/

<Zakim> Ben_Tillyer, you wanted to say that a lot of people see stock images used as 'filler' to be decorative

<alastairc> +1, un-hidden decorative images (e.g. file names) can be v. problematic.

<bruce_bailey> I am sure Dan means not having alt="" versus skipping alt attribute

<Ben_Tillyer> +1 to Scott, I would love "image is decorative but press [key] to hear some information about what the image conveys"

<kirkwood> design element: to help understanding (cognitive access importance) can end up being decorative. Therefore the PURPOSE is important. (as defined by author)

<bruce_bailey> @Ben that is too much noise !

<jeanne> +1 to help people identify when to use alt text. Accomplishing a task is a measure.

<dan_bjorge> As a concrete example, it would be a disaster if we accidentally created a requirement to announce the bullet point glyphs in front of unordered list elements

<jeanne> +1 dan and bullet points

<Zakim> jtoles, you wanted to say that the author's intent is the deciding factor

<Zakim> alastairc, you wanted to suggest "Text alternatives are provided for static images; unless the image is part of an operable control and the alternative is covered by the name of

<kirkwood> +1 Toles

<jeanne> +1 Makoto to limit to HTML to start. There is still plenty of complexity.

<Zakim> Ben_Tillyer, you wanted to say the opposite side of what I said last time

<Rachael> Text alternatives are provided for non-decorative, static images; unless the image is part of an operable control and covered by the control name

<alastairc> Text alternatives are provided for static images; unless the image is part of an operable control and the alternative is covered by the name of the control.

<kirkwood> I’d like to see “design element” in there

<alastairc> (removed non-decorative scoping)

+q

<Zakim> Rachael, you wanted to move us on

<Rachael> Text alternatives are available for operable, non-decorative, static images

<bruce_bailey> WCAG 2 definition for "pure decoration" is a high bar IMHO

<bruce_bailey> https://www.w3.org/TR/WCAG22/#dfn-pure-decoration

<bruce_bailey> serving only an aesthetic purpose, providing no information, and having no functionality

<Rachael> text alternatives are available for images that are not purely decorative

Laura: Whenever a null alt attribute is used the author is deciding that informing a person who is blind that the image on the page isn't important or worthwhile for them to know about. The fact an image is there is completely hidden from them. It removes agency from the user.

<graham> If an image adds information to a page, it should have a text alternative that explains the image content in it's current context. Images within controls follow naming conventions detailed in controls and are exempt from this SC. (we should not cover "naming controls" within text alternatives and cover that in controls instead)

<Rachael> text alternatives are available for images that are not purely decorative or part of an operable control

<graham> that is my starting suggestion

<alastairc> Text alternatives are available for static images, unless the image is part of an operable control and the alternative is covered by the name of the control.

Laura: Just because an image displays something fanciful doesn't mean it isn't worth describing. Announcing its presence ensures that anyone, regardless of ability or circumstance, can fully understand your digital experience.

<Ben_Tillyer> A kind of "None/Few/Some/Most/All" user choice?

<alastairc> mbgower so remove the 'unless'?

<bruce_bailey> +1 for "available" in that it allows possibility that low-information images can be ignored

<Zakim> Rachael, you wanted to shift us to decision tree for all images

<Makoto> +1 to Laura. It can be a good practice to describe decorative images for some users.

<Rachael> https://www.w3.org/WAI/tutorials/images/decision-tree/

+1 to jeanne

<kirkwood> +1 Jeanne

<kirkwood> does it add meaning

<bruce_bailey> +1 for "does this image help a person accomplish a task"

<mbgower> Is this image very unimportant or very important?

<mbgower> Is this image either very unimportant or very important?

<kirkwood> does it add meaning to page?

<alastairc> Does the image convey something meaningful? (If removed, the meaning and function of the page would be unaffected)

<bruce_bailey> +1

<scotto> i still think we should think of a 3rd bucket for "nice to know" to help move away from the boolean of "it's important" or "it's not important so therefore decorative (ignore)"

<bruce_bailey> +1 for 3 (or more) buckets

<Nayan> I would ask - how do you test for this?

<Nayan> plaintiff lawyers are running automated tests in a pass/fail way - so if there is no image

<alastairc> Nayan - we'll get to that, it's a level down from here

<scotto> 1. required to understand or use the content. 2. optionally useful as supportive/tangential information, where if ignored the primary purpose of the page would remain understandable. 3. decorative - the image provides no direct value. if it was removed there would be no loss of important or tangential information/functionality

<Nayan> okay

<bruce_bailey> I like asking page author to remove background images when they assert image is pure decoration -- test is to see how upset they get...

<mbgower> Test 1: has the author flagged very important and very unimportant images?

Laura: How about emotionally rich images?

<kirkwood> graphic designers are just decorative ;)

<jeanne> +1 Bruce, although testing how upset they get could be tricky. :)

<bruce_bailey> But I disagree with Laura's argument that alt="" removes agency. Noisy ALT also removes agency.

<jeanne> +1 -- noisy alt cannot be skipped.

<Zakim> mbgower, you wanted to say that if the user can control whether their AT skips 'very unimportant' images, that is giving them more agency, than all alt="" being completely ignore

Laura: , an author should seriously consider if an image is purely decorative. If it isn't, they should try to concisely explain what the image is in the context of the document's purpose without overly duplicating the text in which the image is embedded.

<alastairc> I worry we're complicating things where currently we only have 2 options, have alt or hide.

<kevin> +1

<kirkwood> design elements have inherent saliency that add important meaning promoting accessibility in alignment with aurhor intent

<Zakim> Rachael, you wanted to talk about research and tech changes

rsagent, make minutes

<mbgower> ALT important/unimportant AND AltDesc="string" doesn't strike me as that complicated

<kirkwood> I think we should add a “design element” maybe artifact?

<mbgower> I'd even like to get to ALT important AltShort="string" AltVerbose="long string"

<Ben_Tillyer> @mbgower why not take it even further, AltShort, AltVerbose, AltSimpleLang, AltAAC....

<mbgower> Most visual information on pages now is not in regard to an image. It's in regard to the justaposition of chunks of content and the use of white space.

<jtoles> If the image is unimportant...

<graham> aria-describedby I think serves the purpose you would want alastairc, obviously requires an element on page to point to but allows additional info

<Ben_Tillyer> @jkirkwood, do you mean something like <span>Start</span><img src="right-pointing-arrow.png" alt="towards"><span>End</span> ?

<jtoles> I think important/unimportant is acting as an alternative to informative/decorative

<ljoakley1> do we differentate between captions and alt text?

<kirkwood> does it add understanding to the overall page. (sa positional layout, priority, graphic elements, visual relationship)

<dan_bjorge> Do we actually want the bar to be "the image itself is operable", as opposed to "the image is part of an operable control"?

<alastairc> ljoakley1 - yes as one is visible, the other is an alternative to the image

<ljoakley1> thank you

<alastairc> dan_bjorge - that's why I wanted to scope it out at the outcome level

<bruce_bailey> There are many good articles about alt depending on the context of image less than the photo itself

<bruce_bailey> here is one https://accessibility.huit.harvard.edu/describe-content-images

<kirkwood> “does it add context?” -good pt

RM: thank everyone for our progress.

This is scribe.perl Revision VERSION of 2020-12-31
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/as Georgia/at Georgia/
Default Present: Laura_Carlson, Rachael, Jennie, dan_bjorge, ljoakley, Makoto, bruce_bailey, jtoles, dj, alastairc, kevin, julierawe, Poornima, scotto, mbgower, giacomo-petri, maryjom, ashleyfirth, graham, Kimberly, NayanPadrai, Ben_Tillyer, JakeAbma, Francis_Storr
Present: Laura_Carlson, Rachael, Jennie, dan_bjorge, ljoakley, Makoto, bruce_bailey, jtoles, dj, alastairc, kevin, julierawe, Poornima, scotto, mbgower, giacomo-petri, maryjom, ashleyfirth, graham, Kimberly, NayanPadrai, Ben_Tillyer, JakeAbma, Francis_Storr, ljoakley1
Regrets: RobertoS
Found Scribe: laura
Inferring ScribeNick: laura

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

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.)