Wilco Fiers was introduced to EO participants. Wilco is leading the Auto-WCAG Community Group, formed to develop automated WCAG monitoring and testing. Shadi led the next discussion about the WCAG-EM Report Tool. Shadi asked participants to review the prototype of the tool on GitHub and comment, bearing in mind that the purpose of the tools is both to give new evaluators a good foundation to jump right in as well as to provide experienced evaluators with an integrated approach. Next was a reminder that final review comments are due for WCAG-EM, considerably revised with EO input and other public comments. If EO participants have more to say, do it now. Next up was a review of the response to EO comments on longdescription. There were no objections voiced and Bim was going to do a final review after the meeting ended. Shawn reminded all of the upcoming Face 2 Face Meeting at TPAC, registration is open, please respond as soon as you know whether you can attend. She also asked for input early next week on the Personas within the Planning and managing accessibility wiki. Finally, Eric updated the group on the progress WAI Tutorials and asked for continued input.
<shadi> Wilco Fiers
<shawn> http://w3c.github.io/wcag-em-report-tool/dist/#/
Shadi: The idea is to take WCAG-EM - the website accessibility evaulation methodology - which explains how to evaluate an entire website using WCAG. It's in a formal spec format, and ready for incoporation into national policies, but this is not the most useful way of putting the info into the hands of people
... so we are looking into how to make a tool to help have more uniform testing processes. However there are a lot of differences... some people just do evaluation; sometimes an evaluation is more comprehensive looking for repair. The tool needs to accomodate these different procedures.
... what you record and what you may want to have in your report may be very different!
<shadi> http://www.w3.org/WAI/eval/template
Shadi: we do have some ancient evaluation templates... I'm not sure to what degree it relates.
... we would probably want the reports generated by this tool to be aligned with the ancient template
Shawn: I think alignment to, rather than being bound by, the old report template.
Shadi: Agree.
... The tool you will see today is a very early protoype, just to show the idea. Don't get hung up on the detail. We would intend to reduce the amount of text from what you see here.
... Take e.g. page on sampling - we'd want a help button which pulled instructions from the methodology to tell you what to do, but the tool's default presentation should be simpler.
... focus now is the kinds of functionality to consider.
... steps come from the EM, and in the end the tool helps you generate a report on what you have. And now, over to Wilco.
Wilco: thanks Shadi. Firstly, are there any initial questions? What this is, what we are doing?
Wilco: we're trying to help people who are new to Accessibility evaluations to be able to pick up this tool and dive right in.
... secondly to allow people with more experience to make use different styles and ways of reporting.
... the opposite to this flexibility is to give people who are new a way of flowing into that without too many instructions.
<shawn> +1 to helping newbies AND flexibility for advanced
Shadi: tell us more.
Wilco: The tool will be entirely client-side. js and some frameworks for prettiness
... You open the tool, go through the EM step by step, and if you want you can export to save data locally, or import a saved file to start from where you left off.
... final report is then an HTML report which can also be downloaded and saved.
Shadi: this is mainly for practicality. If we store the reports on the server we'd need to password protect it somehow.
... then user management, blah blah. Much easier to keep it client side.
... the tool is being developed in github, so extensions are easy.
... that's enough intro. Let's go look at specific functions.
Shawn: any questions at this point?
<shawn> EOWG Comments: https://www.w3.org/WAI/EO/wiki/Feature_requirements_for_Interactive_Guide_to_Assist_Managing_Web_Accessibility_Evaluations#EOWG_Comments
Kevin: I commented to ask if it was a hosted service or single download. Why not go down the route of a user managed service, as it opens up a lot of opportunities. Is it a hard and fast decision?
Shadi: Yes. For now.
... our lesson from the previous tool is it creates legal complications.
... to host user/project data
Kevin: but you could take the pulse of the accessibility of the world by keeping hold of that data
Liam:I have the same question. It seems WAI could do could do both. Don't need to hold all of data in server, just what you want, e.g., what things fail the most.
Andrew: functionality question. ATAG?
... can you drop a screengrab in as part of your reporting, for example?
<kevin> +1 screen capture feature
Wilco: not in the current plan. But agree it would be a nice feature.
Andrew: we use screen captures a lot.
Shadi: we'll record screengrab functionality as a feature requirement, and put compliance with ATAG into the requirements as well
<shawn> Liam: Can we report directly into git?
Shadi makes positive noises.
Shadi: That would be a feature request.
... perhaps a v2 thing.
Wilco: but it's really easy.
Shadi: there will be many easy things.
Shawn: good feature requests = more funding for version 2
... are there any other EO comments to address?
<Wayne> Could this be created in a format that enables alternative stylesheets.
Shadi: hosted service: not planned. Shared data: on wishlist. Missing conformance targets: need to look at that.
Kevin: it is actually in the tool, was just missing from the reqs.
Shadi: customisation of the reports: the tool generates a skeleton report for you, you then continue to extend the report. At least in v1, we did not plan a report editor.
... you can then convert the skeleton to your favourite format. PDF, for example.
Shawn: please make a note of whether we're explaining that clearly.
... that they are report skeletons you can then customise
... add your logo, CSS etc.
Shadi: so front page should have less about eval and more about what you can expect from the tool.
... warnings pass/fail: Kevin please say more.
Kevin: The idea of pass/fail is absolute. It's useful to highlight ones which are passes which could cause problems, but aren't big enough to be a fail.... or items where there is a single instance of fail.
... this is common in the UK. But unclean, impure.
Shadi: no. PASS/FAIL.
MoSCoW
<shawn> Liam: we do use pass/fail and also MoSCoW
<kevin> http://en.wikipedia.org/wiki/MoSCoW_method
Must/Should/Could/Won't
<kevin> +1 for MoSCoW feature request
Also differentiating between bug and feature request
Wilco: this can be extended by other devs
Shawn: so we need to let people know that they can extend
Shadi: We could possibly add a column in the report about priority, add as feature requirement
... any of those additions will be separate from the result ... a success criterion is either PASS, FAIL or NOT PRESENT (an implicit pass).
... those are the outcomes for SCs, but yes we can add more columns like metadata
Wayne: can it be more responsive for zoom/large print?
Shadi: there are bugs right now in the styling, apologies if problems
Wayne: it's actually pretty good
Shawn: Wayne can you send specific things to the EO editors listfor Wilco to collate.
Wilco: responsiveness will be a requirement
Shadi: last question on the wiki then - start and come back. Yes. We call it import and export. We will look at the labelling of that.
... at any stage in the process you can save the data, pass it around, import it and you're back to where you were.
Eric: another feature request: Should it work with browser storage? Will it be possible to use offline (HTML5 style).
Shadi: not sure how widely supported local storage is - Wilco and I will look at it. We know where you live. (non-threateningly).
Wilco: I will add as feature requirement
Shawn: we will need a whole page on 'about this tool' - cramming it onto the first page would be bad.
Shadi: Yes. There's also a Help page.
... wondering if 'about' for normal people, and another for devs.
<shadi> http://w3c.github.io/wcag-em-report-tool/dist/#/audit/test
Shadi: let's go look at the steps. Most of it is not working right now. When you get to step 4 ('test'), there you can check off the SC's to say PASS/FAIL... that will be part of generating the report... if you have thoughts on this, esp those who do evaluation, would this tool be helpful to you in your daily work?
Kevin: regarding the 'test' page, one thing I find when auditing is that some issues are site-wide, others are specific to individual pages. Do we want to capture site-wide issues as a separate chunk?
... also section-wide issues.
Wilco: a good idea, something I'm looking into.
<shawn> +1 to kevin - sitewide issues vs. page-level issues
<Andrew> +1 to kevin re site-wide issues vs page-specific issues comment
Wilco:Thanks to you all for your feedback. Bye.
Shadi: you can always go back and forth between the steps. The 'finalise the report' steps can be added to, then back into the testing, then back to the finalise bit. We're also looking at having a scratch pad for notes as you go.
Shawn: I want to save as I go.
... I am easily distracted.
Shadi: right. whatever we do, we can improve the saving steps (keyboard shortcut).
... Ctrl-S or whatever the shortcut is.
Andrew:can that be part of 'setup' - where to save and under what name?
Shawn: so easy and clear save.
... please everyone add comments to Wiki, Github, or email, whichever is easiest.
Shadi: we're going to keep the feature list in Github. Add them to github. If you can't, let us know and we'll add it for you.
Shadi: keep the ideas coming. We are going to scope carefully to get v.1 out, but none of the ideas will be lost.
Kevin: can you add info on how to do it in GitHub?
Shadi: yes, we'll add to the wiki page
Shadi. Thanks all, looking forward to your ideas.
Shawn. WCAG-EM is oging through its final edits, then the task force will be asking different groups for review. this will be the publication as a full version (not draft). Speak now.
Liam: I'll have it reviewed... in a week.
Wayne: I'll read it.
Shawn: keep an eye on the EO maling list for a note that it's ready and a survey.
Shadi: The plan is to keep the survey open Monday to Monday.
Wayne: If it's there on Monday I'll comment by Weds.
Shawn: and we can discuss on Fri. Wayne should put comments straight into the survey, we can review on Fri.
... in case of changes, but easier on wayne to enter in one place.
Wayne: really Monday?
Shadi: Yes.
... so some background: changes from last working draft: we've moved some sections around. Considerable editorial work, but no changes to meaning. Took all EO comments on board as regards writing style. We're hoping there won't be new issues, although of course any new ones will be noted. But intent is this to be one last check to see we got everything in order.
Andrew: I'll try to review.
<shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2014AprJun/
<shawn> http://lists.w3.org/Archives/Public/w3c-wai-eo/2014AprJun/0061.html
Shawn: they did everything we asked.
... just wanted to make sure we were happy with how they implemented those. Particularly Bim and Eric.
... Eric can you review at end of the call?
Eric: Yes
Shawn: can you look at it right after the call?
Bim: yes
<shawn> Reminder: EOWG f2f Monday & Tuesday 27-28 October 2014 in California, with W3C TPAC - registration open
Shawn: celebration of the 20th anniversary of W3C, and 25th of the Web.
... gala dinner. Hope you can make it. Registration is open.
no questions.
Shawn: work for early next week
<shawn> work for early next week: Review updated Personas - note Questions for EOWG to consider https://www.w3.org/WAI/EO/wiki/Planning_and_Managing_Web_Accessibility#Personas
<shawn> Questions for EOWG to consider https://www.w3.org/WAI/EO/wiki/Planning_and_Managing_Web_Accessibility/Feedback#Personas
<shawn> https://w3c.github.io/wai-tutorials/tables/
Shawn: main thing to look at is the tables tutorial organisation. Over to you, Eric.
Eric: I have implemented everything that was said last week for the tables reorganisation. (lists many types of table)
... the most important thing was that we agree the organisation is good as it is now.
... one thing I didn't do: adding the table where it isn;t clear which column was what to the first page. I've added it to the most directional tables page
... did people have time to take a look, and what did they think?
<yatil> https://w3c.github.io/wai-tutorials/tables/basic/#table-with-header-cells-in-the-first-column-only
<Wayne> This really looks clear.
Shawn: what happened to first name, last name, city?
<yatil> https://w3c.github.io/wai-tutorials/tables/multi-directional/#table-with-ambiguous-data
Eric: I've put that onto the multidirectional tables page as the first example
Shawn: OK, got it
Eric: we wanted to demonstrate that if you changed from a header row to a header column that the data got less clear. Second example conveys that well.
Eric: additionally I've added example with headings to capital cities table that we talked about last week, and changed the text a little.
Andrew: changes into github or via email?
Eric: github
Andrew: you are managing the forks?
Eric: Yes, git for preference
<yatil> https://w3c.github.io/wai-tutorials/tables/irregular/#table-with-two-tier-headings
Eric: Teddy bears from mars were Shadi's suggestion.
Andrew: I like the way you are now stepping through the different levels of complexity.
... I'm wondering if in some of the examples, the action should be to simplify the table rather than code them in a complex way.
Eric: see example 3 on that page where we advise people to split it up if they can.
... but they need tools at hand to mark up more complex tables for when they cannot split.
Shadi: and the tips are quite elaborate on the FAQs
Shawn: reference example 3 from first para
Shadi: I should be neutral but I love it.
Wayne: putting multidirectional tables in it really makes it clear.
Shawn: I love having one page per idea.
General comments of happiness.
Shawn: Good job eric
+1
<kevin> +1
<shadi> +1
Shawn: any other comments on organisation or splitting up the tables?
Nope.
<yatil> https://w3c.github.io/wai-tutorials/tables/caption-summary/
<Andrew> definitely +1 to reorg
Eric: so next changes - caption summary
<shawn> +1 to moving the wcag techniques on the caption & summary page
Eric: notes refering to WCAg techniques were right under the summary bullets, we have moved them.
... to the relevant subsection
<yatil> https://w3c.github.io/wai-tutorials/tables/caption-summary/#using-the-summary-attribute
Shawn: any comments?
No. All good.
<shawn> mobile https://w3c.github.io/wai-tutorials/tables/tips/##On+mobile:+
Eric: next thing: writing something about mobile. That's now in tips
Eric reads out the bit on mobile: "On mobile: Due to the layout model of tables, they sometimes don't fit on small screens. In such circumstances it's important that the table isn't cut off (for example by using overflow: hidden in CSS). By using overflow: scroll on an element wrapping a wide table, the table won't break the layout of the page while being completely accessible."
Shawn: the other wording is imperative: 'do this', but the wording is different here. Is it just a suggestion?
<shadi> "while being completely accessible" -> "and will be more accessible too"
Eric: there are several different approaches, such as splitting them up using js. Saying 'do this' would not be right on this.
<shadi> [[avoid "completely accessible"]]
Shawn: are we saying 'here's one option of several' here?
Eric: it's something I want the reader to consider, and I provide one solution of many.
Shawn: if there are many do we need to make it clear? Why this one not others?
<yatil> +1 Shadi
Eric: this is the most basic solution. Others involve scripting, not appropriate to the tips section.
Shadi: this is different from the note on mobiles in the image maps section. Because we show an example and want them to follow it we need to warn them of its limitations.
... does this also apply if I enlarge tables on a normal screen size
Wayne: it's more complex. If there is a caption on multiple fields...
[Wayne explains about the issues, muffledly.]
Shadi:do you mean we should explain to avoid overflow: hidden in css. Examples listed would be increasing table size on desktop, the other would be mobile.
Wayne: yes I like that. Also I was thinking in the beginning that a simple approach that works in general - avoid this in most situations
Shawn: clarify that we should not use overflow hidden in css
Wayne: so if x then you must y
Shawn: Eric can you put your summary of what you think we want into the minutes?
<yatil> Rewrite proposal: Use overflow:scroll on a wrapper element to make sure the table is more flexible in the page layout. Do not use overflow:hidden to cut off parts of the table. This helps with zoom and mobile.
Shadi: Wayne was saying it's more complex than 'makes sure' - we need a conditional 'to make the table more flexible'
Kevin: when we we're talking about overflow:scroll not being the only solution, should we note that there are other ways, but we're not going to go into them..
Andrew:Can we say that "one way of addressing the problem is ..."
Eric: yes, we could write that we use the overflow:scroll method in the tuts, but tell people that there are more options.
Shadi: Ahhhhhh.
... we are listing this particular element because we are showing it in the example. But don't want to complicate the wording! But want to explain why we are talking exclusively about this element
Eric is happy.
Bim: Does anybody know if there is a keyboard way to sideways scroll?
Liam refuses to minute Bim's hack.
Andrew:in chrome I just use sideways arrow keys
Shawn: UAAG issue
Wayne:It is a serious problem. Keyboard access to horizontal scroll in tables.
<Bim> https://w3c.github.io/wai-tutorials/tables/tips/##On+mobile:+
<shawn> https://w3c.github.io/wai-tutorials/tables/tips/
Shadi: currently on tips page at the end there is a note
... should it not just be a bullet?
Eric: we also have an FAQ question related to layout tables... and I don;t want to mention them at all, really.
<Andrew> +1 to layout tables as bullet rather than 'a note' - highlights it better (and is different from the FAQ)
Eric: we should not bring layout tables into the focus.
Shadi: and WCAG-WG have asked to remove the note?
Shawn: proposal 1 - we have one bullet that has a note on layout tables and it says 'don't do it and if you have to use role="presentation", and we delete the faq.
<Andrew> +1 to Shawn
Shadi: proposal 0 - keep as is.
<Bim> +1 proposal 3
Shadi: proposal 2: it to remove the note because we have a FAQ on is
<Howard> +1 to proposal 1
<Wayne> me, Observation: Data tables are really a set of tuples mathematically. The rectangular grid we generally call a table is really just one presentation among many. It is just as reasonable to represent a table as a list.
Andrew: if it's in an FAQ then you haven't explained the topic properly. If they are frequent, then why haven't we explained them earlier.
<Andrew> https://gds.blog.gov.uk/2013/07/25/faqs-why-we-dont-have-them/
Shadi: we don't have to have an FAQ for the tutorial... but there may be questions that emerge over time. Both pieces of info in the FAQ coupled be formulated as Tips and we can remove the FAQ for this particular tutorial.
Shadi: and...?
... we should remove the FAQ completely from this tutorial, and keep the info in there as tips under the relevlant bullets
<Wayne> +1
+1
<shawn> +1
<Howard> +1
<yatil> +1
<Andrew> +1
<metzessive> +1
<yatil> https://w3c.github.io/wai-tutorials/images/tips/##text+instead+of+images
Liam: I am impressed with Eric's cool URI
<Howard> maybe the paragraph should just be proceeded by a "No."
<shawn> If we decide to do something like this, suggest different wording, e.g., "Should we provide a text-only version without images?" or such that does less to perpetuate the myth by itself. (also note it will take a little effort to craft a good, succinct answer) {Shawn, 2014-Jun-06}
Shawn: maybe something like 'I heard text-only versions were bad'
<shadi> +1 to shawn's idea
<Wayne> +1 as well
Bim: Images also help screen reader users when other structure isn't available.
Wayne:Separate by its very nature is inherently unequal
<shadi> +1 to Bim
Shawn: ok, let's try to wrap up the tutorials as soon as we can.
... comments as soon as possible please
<Wayne> We just proved at CSU Long Beach that screen magnification slows reading significantly when compared to enlargement with word wrapping.
Shawn:Thanks everyone, watch the wiki and GitHub and respond as much as you can this week to get everything wrapped up - thanks again!