<shawn> scribe: Sharron

WAI Curricula Project Updates

Daniel: First we did approve the email that EO can use to do outreach for a Task Force to focus only on the curricula. Next we are working on the draft for Creating Accessible Content. Thanks for the feedback you provided in the survey. We have several suggestions that I am processing. Next steps will be to present to the Task Force next week my plans for restructuring. Any comments or questions.

Shadi: The email is to invite people to contribute to the work, not necessarily to join the Task Force. The contributions could be less that TF participation.

Brent: Is there just the four of you on the TF for now, or are there others?

<shawn> Sharron: DId outreach to TeachAccess?

Daniel: I have some interest from another person
... but not finalized

Shawn: I contacted Kate and could followup

Howard: Shall I send out to the faculty Working Group?

Shadi: Sure that would be helpful and it doesn't hurt for people to hear from multiple places.

Brent: Any other comments?

ATAG Repeort Tool

Brent: We have had an open survey. Hidde wanted to use the GitHUb bot for the agenda/minuting of this

Hidde: Quick intro and then we can start a new topic to support the bot.
... there have been many issues and some have been processed. A subset of issues have been marked for discussion today and were part of the survey.

ART Austosave

<hdv> GitHub: https://github.com/w3c/wai-atag-report-tool/issues/107

Hidde: A complex issue, I put a lot of info to summarize. Thanks to all who read through and commented. Seems like we are tending to yes, we want that option.

<shadi> +1 to moving this feature to next version if it takes more time

Hidde: even if it is useful, it is also time intensive and so we have to consdier if we want it. Also need to understand how to expalin it in the intro. What happens is that your observations are put in the browser but saving is browser specific. Don't want to say "we will always save your data." My suggestion is to say "saved to browser but export frequesntly as backup" See the last comment in the

GitHub.

Hidde: What I want to capture is that browsers address this differently and we do not want to give a false warranty.

Shadi: I am having trouble getting the ART to run?

Hidde: Need to clear your cache more frequestly while in dev. I will send out an update later today that will fix that.

Shadi: Is this issue related to auto-save?

Hidde: No something else, sorry about the problem.

Shadi: I wonder if it needs a bit more explanation about the need to clear cache before proceeding. My concern is how easy it may be to find the clear button and the ease of understanding how the tool works.

<Zakim> kevin, you wanted to say that there are a lot of mights and maybes in any such statement

<hdv> Howard: https://atag-report-tool.hdv.now.sh/

<shadi> https://atag-report-tool.hdv.now.sh/

Kevin: With all the contingencies about how browsers may behave, that is a complex issue to communicate.There are many parts that are almost contradisctory and that will be hard to clearly communicate.

Hidde: These are issues that many people will not even encounter.

Kevin: Why does it need to be explained in that case?
... what is the user need that is met by explaining it?

<Zakim> Howard, you wanted to ask that a link to the atag tool be placed in IRC

Shadi: What happened for me is that I did some work, came back a few days later and did I thought was a new reprot and found old data. I did not expect that behavior and had not encountered it before.

Kevin: When you came back did you click "Start New/"

Shadi: No I followed the steps.

Kevin: So maybe the best is to expose the two. Start a new evaluation -OR- veiw current evaluation.
... you do not then need to make a complex explanation.

Hidde: Yes that is a great idea

Kevin: That would mean you did not have to explain, just force the choice.

Sharron: +1

Shadi: This really gets to the crux of the issue in my view, not opposing this feature at all. I do have the feeling however that we are getting into a more complex design. Do we want to spend more time now, is it a feature we need or postpone for another version?

Hidde: At this point, not much more design work needs to be done. Adding what Kevin just said will reinformce the behavior and is a samll change. Good enough as it is.

Brent: Not just the design work but also the support and testing to be sure it is exactly right.
... so have to consider 1. is the way it is now good enough and 2. should we delay for a future version?

Howard: The problem I have is that I get a generic blank page when I land, the tool is not showing.
... it will open in a provate window, how would I know to do that and if I clear it in a private window the public one is still not showing the tool.

Helen: I had issues in Chrome as well. Would it help f instruction were on a Help tooltip or otherwhere than the page itself?
... I think the autosave is good. If the interaction will be complext for the user, it needs to be supported.

Hidde: Will only need to explain for those who find this to be unexpected behavior.

Helen: Exactly why to keep it hidden unless needed.

Laura: I would agree that we should try to include in the first version - it is useful despite the confusion. Agree it is misleading to call it autosave but find it useful enough to do the extra work to provide if in this version if possible.

Hidde: The better word might be local storage

Brent: Getting a pulse...how amny think this feature should be included and worked out before v1 release

Hidde: Note that removing the feature now will also cost some time.

<Helen> +1 release with it

<mpalmer> +1 for including the feature

<Laura> +1 to include

<Howard> +1 to include

<krisannekinney> +1 to include the feature.

<eoncins> +1 to include

<brent> +1 to include

<kevin> +1 for the feature

<Daniel> +1 to include

<Howard> Hidde - now working in Chrome

Brent: One thing is to let us know how long this will take to finalize, maybe talk with the planning team. Did you get enough information from the discussion or need to continue that?

Hidde: How long it will take - it means to clear the evaluation when someone chooses "start new" and deciding that the buttons would mean less need for an explanation.

<shadi> "This tools saves information you enter locally in your browser for backup..."

<shawn> +1 for wording ^^^

Shadi: The tools saves information locally in your browser and may need to be cleared before starting a new evaluation...or something like that.

<Laura> +1 to Shadi's description already

ART Metafields

Hidde: This is a tricky one since we discussed adding several options. Have added the level of conformance and have consdiered others...

in the survey date of eval and version of report seem to be most preferred

Sharron: Happy to leave to editor's discretion

<mpalmer> +1 to both on the basis that date alone might not be specific enough

Shawn: If it only those two options to choose from, version of this report is more likely to be confusing and so mildly say go with date.

Kevin: As metadata, I would go with neither of the above
... date is already captured and would not use version becasue it oes not give you anything useful and hass the risk of confusing with version of the tool
... at the end of the day people can export data and manipluate it as they choose.

Helen: I feel slightly responsible since date may not be enough and suggested a free text option.

<shawn> brainstorm: Evaluation Reference

<shawn> scribe: Kevin

Shadi: Reference is a too vague.
... I like what Kevin said. Hidde, would it be possible to have date of report appear in the report section at the end but be editable? So, auto generated but easily changed.

Hidde: Yes, but that would then be functionality that doesn’t exist; editing on the report page.

<Sharron> Scribe: Sharron

<kevin> Shadi: In the report tool the Executive Summary and adding a date at the end was important.

<kevin> … Version of the report could be included in the summary.

Shadi: The experince from the report tool suggests they may do it across several days but wnat to note one specific day as the report date

<Zakim> shawn, you wanted to agree and diagree with Kevin :) and to say think Executive Summary should be on last page, too and to say Evaluation Reference and the default is date? that is

<kevin> Hidde: Executive Summary is probably a good thing.

Shawn: If you ahve an auto-date it should be editable. The Exec Summary should be on the last page. Brainstorm: Eval reference number is an option and by default it is the date and people can change it to whatever they want
... most people are going to download the report and change it how they want so this may be a point that we want to make flexible to recognize that people will do what they need.
... defintely should be editable.

Hidde: Date format?

Shawn: Will share the style guide

<shawn> [ date format in WAI Style Guide https://www.w3.org/WAI/EO/wiki/Style#Dates]

<shadi> [ https://www.w3.org/WAI/eval/report-tool/#!/evaluation/report]

Brent: I am thinking of the use case, as I use it over time I would not want the date to be when I start. The purpose for having a date away from the tool one of the first questions will be 'when was this done?' I would want the date of completion not the date of starting

<shadi> [ https://www.w3.org/WAI/eval/report-tool/#!/evaluation/report I think uses local format but allows any format (ie. you can edit as you like) ]

<hdv> [ issue for 'Download HTML' button: https://github.com/w3c/wai-atag-report-tool/issues/72]

<shawn> -1 for download date not change-able

<Daniel> I like date by default, but editable.

Brent: As far as saving an HTML version of the report, how do you indicate that? some people may think JSON is the only option?

Hidde: There is an issue raised about this already

Shawn: I am not in favor of default download date, much prefer current date that is editable.

<kevin> +1 to one date, defaulted, and editable

Brent: I would want to know the date of download when I hand it off.

Shadi: If you have the date and can edit it, you can also choose nt to edit it and that satisfies the use case right?

Brent: yes and meets Shawn's request as well.

Hidde: I can do a mock up for how that can look. To separate a place where you changed it and a place where you look at data. Will do the mockup and come back next week.

<shawn> +1 Hidde. thanks!

Shadi: I like that

ART explanation of markdown syntax

<hdv> GitHub: https://github.com/w3c/wai-atag-report-tool/issues/89

Hidde: We have two places at the moment where we explain that you can use it on the start page and as well on each input box. Some found it annoying, including among screenreader users. Does the use of it justify the level of annoyance. I came up with a soghtly different approach - it is here.

Daniel: I think we need to avoid so many tab stops. I get the idea that the markdown syntax is usful but may not need so many reminders
... may not need to appear in each box, maybe once or twice in a page

Hidde: Byputting markdown supported in the tip sheet
... not how to use markdown but just to let people know it is markdown supported

Shadi: The markdown supported currently has too prominent a position, can it be a bit less so?

Hidde: It is there so people know how to see what it looks like.

<brent> +1 to bottom right (if we decide it stays for each box)

Hidde: for me it is a remnder of what content can I put in here

<Zakim> shawn, you wanted to say still prefer not 52 times. still think not needed, except in How to Use (changing heading instead of Tips). OK to bow to others. brainstorms: at the top of

<scribe> Scribe: Kevin

<Laura> +1 to the top of each page

Hidde: If it is only in tips, I worry that most people won’t see it
... It is also good to be in the component as it can be clearer which ones do and don’t allow markdown

Shawn: It is not important information. If someone forgets it then it is not a big issue.
... I don’t think it is a huge deal for those who just jump in and use it. I think most users will skim first page.

Hidde: I think that is important to encourage people to use structure so I think this is an important feature.

<shawn> difference between *important* and *helpful*

Hidde: More clarity and formating actually helps the report recipient.

<Laura> +1 to Hidde's comments on structure

Brent: In other implementations around the web, if there is a tool or form where you realise that you can use markdown, are you prompted that you can do markdown because there is something that indicates this is possible?

Shawn: It is more whether there are lots of fields telling you the same thing.

<hdv> https://usercontent.irccloud-cdn.com/file/khWLzvs8/example%3A%20'pencil%20icon%20%2B%20Markdown'%20in%20bottom%20right%20corner%20(this%20is%20from%20my%20CMS)

Shadi: For example with GitHub. First it provides an editor which allows for some markdown shortcuts.

<hdv> alt: example: pencil icon + Markdown in bottom right corner (from CMS that my own website uses)

Shadi: Despite GitHub having that, it also does have a reminder for Markdown. It is a small icon in the bottom right hand of the text box.
... It is not that visually prominent and I can’t think of a tool that is.

<shawn> Kevin: Trello allows for markdown, and dones't indicate that it does

Brent: Stepping out of chair, I have to agree with Shawn. It is not critical in order to complete a report.
... If someone does try it then that is good.

<hdv> just confirmed Trello does not display any indication of Markdown support

Brent: The prominence of it is a bit overboard. Good to state it but not important enough to take extra tab stops.

Hidde: The discussion is now about having no tabstop but still having it displayed?

<shadi> -1 to visually prominent -- quite distracting IMO

Hidde: Where it currently is is the only place within the design where it can go

-1 to visual salience

Daniel: Trello do state in their documentation they state that there is support, but nothing is visual.
... I would go further and suggest removing the indicator completely.
... If I encounter an editor, I will try Markdown and check the preview. I don’t really look for an indicator.

Laura: Just thinking about structured data, it does make the developers life easier. Developers are more likely to do something if it is easier.
... That might make digesting and using this data more likely if there is that structure.

Hidde: There are some tools that export to ticketing tools which requires structured data.

Brent: Good feedback. Can we just take a view of the group.

<Helen> -1 to being included on every field

Brent: Should a markdown indicator be included with each observation box?

<Daniel> -1 to being included either as a tab stop or visually

<Howard> 0 I will go with consensus. I like it but am hearing the concerns of others.

<shawn> -1 to be there at all

Brent: +1 if it should be there minimally visually, -1 if it shouldn’t be anywhere with each observation box

-1 shouldn’t be there at all

<shawn> <Helen> -1 to being included on every field

<mpalmer> -1

<brent> -.5

<eoncins> 0 I will also go with consensus

<Laura> I don't know how to answer - I guess I'm not in favor of just visual. I'm in favor of at least at the top of the page.

Brent: It is not a 100% consensus for not there but it is a strong lean.
... Based on this it looks like it shouldn’t be by the observation box. Could be either at the top of the page in the tips.

<shawn> -1 for top of each page

Shadi: I have a mild concern with the top of the page.

Hidde: The icon on GitHub is very subtle, I had to look it up.
... I will remove the reference from the observation boxes.

<shawn> +0.5 for changing "Tips for using this tool" -> "How to use this tool" (which might help people read it more :-)

Hidde: I am keen to encourage structured reports to help developers.

Shawn: I wanted to support Hidde’s last point. I totally agree with encouraging people to use structured. Just in another way.
... I am happy to help to find other ways to do this.

Hidde: Could do with the a placeholder but there are accessibility problems with this

Shawn: We could do this much more clearly in the first page, as well as the opening page, to call out the availability of markdown.

Outreach

Shawn: We have the evaluation videos published now. Sorry for the slight delay. It is great that is just before GAAD.
... Thanks to Hidde for his help in publishing them.
... There are a series of Tweets to try to encourage people who are doing GAAD events to use these videos, and other videos, in their presentations.
... If anyone has some time to help out with some promotion, contacting organisers of GAAD events to use these resources would be really good.
... Particularly if you see someone doing a GAAD talk that matches up with existing WAI resources.

Shadi: Woo hoo!!

<shawn> [ I want to thank EOWG FOR PUBLISHING AND SHARING THE RESOURCES DESCRIBED BELOW.

<shawn> Thank you so much. These will be so helpful as I work toward helping to increase the universal access to digital information for persons with special needs. ]

Shawn: I received an email from an occupational therapist with thanks for all WAI resources. Shows that we are getting good feedback
... The Introduction course has been formally extended through to September. This version won’t be extended.
... There may be an updated version in the future but nothing in concrete as yet.
... Please do promote the course and record that you did so.

Charter review

Shawn: Please ask your AC Rep to complete the charter. All members can see results even if you can’t fill it out.
... If you want to know if your AC Rep has filled it out yet, please do contact me.
... There is also a separate place to put in support statements but it is good to also include those in the survey.
... So far we have 10 positive comments, all supportive with no suggested changes or modifications.

Brent: When does this close?

Shawn: 11th June, but it would be good to get it done sooner. We have to have at least 5% which is about 15 more responses.

TPAC update

Brent: The Chairs were asked to complete a survey on TPAC as to whether we would be having a face to face or virtual. This lead to the face-to-face being cancelled and moving to a virtual meeting.
... Chairs have been asked to provide information on what their plans are for a virtual meeting.
... EO has stated that we won’t be meeting for a long virtual meeting and will continue with our normal meeting schedule.
... There may be an opportunity to participate in other TPAC activities. We will share more when it is known.
... The Vancouver venue has been rescheduled for 2022 as the venue is good.

Shawn: 2021 TPAC is still being planned and Vancouver is scheduled for 2022.
... For next year, we are still looking, possibly somewhere in Europe but nothing has been decided as yet.

Work for this Week

<shawn> s/has been rescheduled for 2021/has been rescheduled

Brent: No survey this week but we will be updating the work for this week. Only thing this week is getting your AC Rep to respond to the suvey and keeping an eye on the ATAG Report Tool issues
... Thank you for all the editors today and Shawn for outreach and charter updates.