– DRAFT –
WCAG2ICT Task Force Teleconference

<maryjom> egrets: Daniel Montalvo, Laura Miller, Thorsten Katzmann, Bruce Bailey, Bryan Trogdon

Announcements

Chuck: WCAG2.2 is expected to be published imminently. WCAG 2.0 errata is going out soon (if not already)

Chuck: Higher level - everything looks fine, and should be published soon. Formal objections are now withdrawn. So will be published as recommendation

Chuck: Also asked about use of WCAG, raised in this group. We were finding cases where people were trying to apply WCAG to specifics such as kiosks without necessarily using other guidance such as WCAG2ICT, which we thought was not so helpful

Chuck: Then asked W3C who would own the messaging around this. Additional info provided: they are not inclined to send a message that says "don't use WCAG in this way" as it might stop good innovative ways of applying WCAG.

Chuck: Better approach would be back channel messaging through personal links. If there was an interest in looking at WCAG through the lens of kiosks, it would be good to form a community in W3C to create some guidance for this, and W3C would be more supportive of this.

GreggVan: The concern was that WCAG was being applied to closed products (kiosks), some clauses require screen reading which they might not have, which was then fed back as guidance that WCAG couldn't be used.
… This is why WCAG2ICT is so useful and required
… Tricky bit about this is you can have closed products that also have AT built into them - so software on them is closed, but platform might have AT built in.

Mike_Pluke: You can apply some SCs from WCAG to closed functionality, but it does need additional guidance, which should point back to WCAG2ICT.

Mike_Pluke: there is a demand for suitable guidance. As an example, spoke with people trying to use EN 301 549 guidance - and there is a demand for help in interpretation or application of standards to other environments

<Zakim> Chuck, you wanted to say that this conversation may be "bigger", and might take up an entire call

mitch11: Re kiosks, agree with all the above. However, an additional footnote - I don't agree that iOS is closed as you can install AT such as Braille readers, screen readers etc.

Chuck:

<GreggVan> +1 to chuck

Chuck: This could be a very large conversation and take up lots of time.

<Zakim> PhilDay, you wanted to say WCAG2ICT should cover these cases, and those who can give input should be encouraged to get involved

<Chuck> +1

PhilDay: Think we should encourage others to engage with WCAG2ICT if they are interested - e.g. kiosks, self-service, closed systems.

maryjom: There could be other activity to give further guidance for self-service or kiosk use, in addition to WCAG2ICT
… This would outside our (WCAG2ICT) work

maryjom: Other announcements. All agreed content on closed functionality thus far is merged into the document.

maryjom: We are still going through the rest of the closed functionality bullets, and will incorporate further changes as agreed

maryjom: We are now starting to work on WCAG 2.2 success criteria so need focus on these new criteria. Volunteers need to pickup issues

<maryjom> https://github.com/w3c/wcag2ict/issues?q=is%3Aissue+is%3Aopen+label%3A%22WCAG+2.2%22

maryjom: link above shows issues that need somebody to work on
… Please consider adding yourself to one of these issues.
… There is also an open survey on 3.3.7, redundant entry. Email just sent out on survey.

<maryjom> Survey on 3.3.7 Redundant Entry: https://www.w3.org/2002/09/wbs/55145/WCAG2ICT-redundant-entry/

maryjom: open until Wednesday next week

mitch11: I still have 1.4.4 resize text to work on it. Would like to invite input on the discussion on this issue.

maryjom: We also have a number of smaller issues to continue working on.

mitch11: Will follow up in email for offline discussion

FPWD public comments

maryjom: We have 1 new public comment (yesterday), issue 221 on reflow

<maryjom> Issue 221 on 11.1.4.10 Reflow as applied to self-service terminals and kiosks. w3c/wcag2ict#221

maryjom: work on closed functionality may help to cover this question, but more work may be needed

GreggVan: Thing with reflow is that you have zoom. Are we assuming there is a zoom - if there is no zoom, then there is no reflow issue?

maryjom: Take a look at the issue - there is some discussion there. Kiosks are often designed without zoom as they have a page by page metaphor, and already have large print

maryjom: Also look at the editors draft, particularly on the bullet for reflow and see if you think this proposed text is sufficient

Survey Results: Review draft updates to SC Problematic for Closed Functionality

<maryjom> https://www.w3.org/2002/09/wbs/55145/wcag2ict-sc-problematic-for-closed/results

2.4.2 page titles

<maryjom> https://www.w3.org/2002/09/wbs/55145/wcag2ict-sc-problematic-for-closed/results#xq17

7 incorporate as is, 1 suggested a change to add kiosk and omit some other language on closed functionality

2 options

<maryjom> Option 1 – as proposed: 2.4.2 Page Titled—Where software is an integral part of hardware that provides a single function, such as a calculator or IP telephone, there is no need for a title. In addition, a software program does not equate to a "page" or "screen" of content that is a step in a process. Closed functionality products often break processes down to a series of screens, each with a single function. Requiring a page title for eac[CUT]

<maryjom> Option 2 – edited (add kiosk, remove everything after first sentence): 2.4.2 Page Titled—Where software is an integral part of hardware that provides a single function, such as a kiosk, calculator, or IP telephone, there is no need for a title. 

Sam: Don't think we should be listing individual items of hardware - instead just give examples of behaviour. Just listing kiosk is limiting

GreggVan: For me one of the fundamentals for a complex item you either have a definition to say what you mean, or you give a few examples
… If they were a full list, then we would have a problem, but a few examples doesn't limit you.
… 2nd part about software programs. Saying that it is distracting to add information is potentially a bad direction - better to say software may not have pages, and therefore doesn't have page titles

Mike_Pluke: Agree that it is useful to give examples. Not sure what the bounds of a kiosk are - so may create more confusion.

GreggVan: 100% agree with Mike. Kiosk is confusing. There are some kiosks that are browsers

mitch11: happy to drop kiosk from list of examples. If software do not equate to a web page, then the whole SC is not needed

mitch11: If they could be moved - could add this to NOTE 1 of this SC.

<Zakim> PhilDay, you wanted to say self service terminals, or something similar

PhilDay: Consider using self service terminal or device instead of kiosk

maryjom: A lot of kiosks self service devices don't have a window or software title - they are single function devices as it doesn't have any other functionality or modes

Sam: Lots of examples - screens on thermostats, small media players, cameras, video recorders. In all these cases there are single use devices, and putting a page title in there doesn't make sense.

<Zakim> GreggVan, you wanted to say the AB uses SSTM and it does include kiosks that are general internet browsers so I would avoid that as being too broad.

GreggVan: Access Board uses Self Service Transaction Machines, and they do include kiosks and browsers. There is an idea of embedded software (not installed) and this a different category to installed software programs. Maybe this is a better definition.
… If the platform has AT, is it closed? This is a tricky question

maryjom: Like the term embedded software. Why would you apply a requirement for a title for embedded software that only has a single purpose

<Zakim> loicmn, you wanted to say that one example could be public transport ticket machine. And to say that we need something explaining alternatives to title (programmatic access)

loicmn: Agree with idea of embedded software - nice way of differentiating from software applications, maybe need a definition of this.
… Another example is a public transport ticket machine. Thirdly, we are missing something - 2.4.2 is problematic for closed because the title can be accessed by programmatic access. This is what we should be talking about here - we should talk about alternative ways of doing things
… Agree with having a shorter version, but we need to give guidance on systems where you can switch between functionality you need a way of telling the user which function they are using if there is no title

maryjom: Think the way forward is to modify the current proposals to use embedded software, have a definition for this, and ...

Sam: Is it only programmatically? Seems like a different expansion of the requirement. We shouldn't go beyond the original SC.

maryjom: Agree that it is not about programmatically determined. Think we go with simple text, referring to embedded software, point to a definition, and then say there is no need for a title. That might be a simple way of approaching it.

mitch11: Embedded software - can mean something else; namely software without a user interface. This is different to how we used it - in terms of how it is installed or modified

<Sam> Wikipedia for embedded software https://en.wikipedia.org/wiki/Embedded_software

GreggVan: The way it is used by US Govt is software that is integral to a piece of hardware. It may have a user interface, or may not.

GreggVan: But do agree that using embedded software could be misconstrued.

<Sam> Example provided by Access board of embedded software https://www.access-board.gov/ict/guide/sccp.html

maryjom: Is option 3 sufficient?

Sam: Are we saying that if we define embedded software is it still too confusing to use, or can we just define it before using?

GreggVan: Dislike defining a term differently to how other people use it. I thought we had agreed that it is a non-issue - we already said under the page title - name of the software is the title - there are no pages in the title.
… If we have something with only 1 function - we don't need additional titles as the first page will already cover this

mitch11: Firstly to answer the question - what is the objection of embedded software? Even if we define it, there may not be a need to use it, so we could just use a simpler definition

maryjom: There are examples of closed functionality that don't have a title (e.g. printer, thermostat). There are cases where it does not make sense for a simple, single purpose product.

<loicmn> In those cases the "title" is the device (printer), isn't it?

GreggVan: Think we have to have something here - maybe for a single-purpose device, the name of the device may be taken as the title.

maryjom: We will continue discussions next week.