Lauriat: We want to start building what we might use as a conformance model. Taking existing SCs and things that didn't get into 2.1 and building things out.

<jeanne> https://docs.google.com/document/d/1aBoQ1HDindVnFk_7Ljp-whpK3zAiqAdgJxsgpqsNpgU/edit

Jeanne: We have a starting point, the work that Cyborg, Luis, and I did over the Summer
... it's a little old, but might still be a good place to begin

<jeanne> Heuristic evaluation to determine if the alternative text explains the issue in the context given. This is a task-based assessment, instead of a component-based assessment. See Table 5 prototype for images of grading scale. The scale ranges from “Can’t Use At All” through “With Difficulty” to “Pretty Easy” to “The Best”. The example for “Finding a Hotel” using an HTML

<jeanne> form, has tasks such as “Perceivable: Identifying the form”, “Understanding: How to use the form”, “Operable: able to complete the form” and “Robust: Code check for HTML compliance”. The tester selects the persona of a person with a disability that they want to check against, and tests using that persona’s restrictions (for example, with mouse unplugged, screen turned off,

<jeanne> etc. That needs to be determined in advance.) The tester grades the experience on the scale. (part of a broader test of more accessibility needs)

Jeanne: Maybe we could look at Example 2, the one starting with "Heuristic evaluation..."
... We could start with the test rules: with the screen turned off; using a screen reader

JF: I'm looking at this. I'm struggling with whether we have a definition for "pretty easy?"

Jeanne: We're looking at that...how do we define that, etc.

JF: Putting aside "pretty easy," I'm concerned that the test rules are focused on a screen reader. Would other rules be as effective and have less overhead.
... For example, the Web Developer Toolbar will provide alt text for every image, etc.

<Cyborg> just got here, so if there was a link pasted above that we're discussing, could someone please repost? thanks

sure, one sec

https://docs.google.com/document/d/1aBoQ1HDindVnFk_7Ljp-whpK3zAiqAdgJxsgpqsNpgU/edit

<Cyborg> thanks

JF: There are ways we can do this testing without a screen reader. There might be a lighter-touch test we can do for the same thing.

Lauriat: Maybe we could come back to this as a way of testing it.

JF: The real test isn't exposing the text alternative, it's whether the alt text is "pretty easy," "the best," etc.

<Makoto> +1 to JF

Jeanne: So how do we determine that the accessible name is correct?

Lauriat: Let's start with "can someone complete the task with the text alternative" instead of the visual presented in the image.

<mikeCrabb> https://www.w3.org/WAI/tutorials/images/

JF: If the image has text burned into the image, I also want to see the image while I'm evaluating the alt text.

mikeCrabb: This has examples of what you would want to have in the alt text

Jeanne: So, what should the scale be?

Lauriat: Right now, we have full page conformance...but for task based conformance, we'd need to figure out how to piece something together.

JF: Text alternatives can get a bit granular depending on how the image is being used.

Lauriat: Why don't we start there...the first step for testing the alt text is to determine the intention for the image.

JF: Well, the first step would be if there is a text alternative. And then what is the purpose of the image.

<JF> Locate each image that can be activated as part of the user interface. If the image is the only element within an interface control, ensure that it has an appropriate short text alternative that conveys the purpose of the control or presents the same information as the image. If the control also contains text content, ensure that one of the following is true: The image has an appropriate short text alternative which, together with the control's text content, convey

JF: from the beginning there are contextual decisions that need to be made

Jeanne: We are envisioning these tests would be part of the methods. I don't think we're trying to impose a method that's required

JF: So there's the doing and there's the verifying. The doing is wide open, the verifying is "you've picked one of the methods" is it good?
... as an evaluator, I need to see what you've chosen to use and does the value string make sense?

Jeanne: Can you see there being a scale for how well it works on the page?

JF: That's why I was wondering what does "pretty easy" mean? I can see it at a high level where a few people could do it, because it comes down to each person's definition of "pretty easy"

Lauriat: Maybe someone has a different definition for "pretty easy" or "fantastic" but they'd both be success. What about something like "complete failure" "with difficulty" and "success"
... like the difference between "Submit" and "Send" for an email

JF: If the alt text is being auto-generated...and they're all "button" so they're useless
... at that point, is it a pass or a fail?
... and it would be a partial pass since it has a text alternative, but the value is useless

Jeanne: That's what we're trying to do

Lauriat: Can the user complete the task based on the alternative text

JF: There would be need to a similar decision tree that is a if/else walkthrough

<Cyborg> To Luis and Jeanne - I added a comment re: the prioritization to the document -- in line with our previous discussions.

Lauriat: I think we should use the same scale for everything...just keep what we have as a strawman and adjust it as we work through things

<Cyborg> changing it from 3 point prioritization rather than 4 point - i thought we went through this

we hadn't reflected that change in this document

Jeanne: Maybe we should provide examples of what measurements on that scale look like

Lauriat: Maybe some scales will work for some tasks, but not others...that could help inform what we end up using
... Let's complete the walkthrough for how to do this for one type of image

Jeanne: I want to give mikeCrabb a chance to talk

mikeCrabb: There were arguments about what the tags in the Information Architecture prototype should be...and not whether we should have tags, so that was good

<jeanne> https://lists.w3.org/Archives/Public/public-silver/2018Nov/0062.html <- Mark Tanner's email on tagging

mikeCrabb: I'll be taking a closer look at it next week when I have more time

Jeanne: We also got an alternative scoring proposal...I invited him to join us for a meeting

<jeanne> https://docs.google.com/document/d/1JXR20WYEYd3mZVRDTpQCMsU2cHwlFPxTbsxQIVVxEwc/edit

Jeanne: I created a google doc for it
... if folks can look at it, we can continue with this next week since we're not meeting on Friday
... and we got more responses from AGWG, if you could take a look at that in the email
... anything new on Plain Language?

Cyborg: I'm more focused on conformance. I was listening to y'all and adding stuff to the document
... separating task-based guidance from product-level guidance, etc.

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)

Present: LuisG Cyborg KimD Makoto jeanne Shawn Jennison Angela MikeCrabb
No ScribeNick specified.  Guessing ScribeNick: LuisG
Inferring Scribes: LuisG

WARNING: No "Topic:" lines found.

Found Date: 20 Nov 2018
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


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