<Gottfried> scribe: Gottfried

FAST - Framework for accessible specification of technologies

FAST checklist (draft): http://w3c.github.io/apa/fast/checklist

Picking a test spec: CSS Overflow Module

<MichaelC> http://w3c.github.io/apa/fast/checklist

https://www.w3.org/TR/css-overflow-4/

Step by step...

If technology allows visual rendering of content: YES

- There is a defined way for a non-visual rendering to be created?

Michael: Is the checkpoint ambiguous or is the category ambigiuous?
... We need ways of capturing CSS, but maybe it is not applicable for some checkpoints.

- Content can be resized: n/a

- Luminosity and hue contrast can adapt to user requirements: n/a

- Text presentation attributes can be changed: n/a

- Visual presentation of pointers and cursors can be adjusted

Michael: Does clipping fail this checkpoint?

- Changing content presentation does not render it unreadable

Michael: Does clipping fail this checkpoint?
... This is applicable.

Gottfried: Is this in the responsibility of the spec authors, or of the web authors?

Michael: If the user changing content presentation renders it unreadable, the technology provides a way to overwrite that.

Gottfried: Or we could ask the spec authors to add a note regarding the risk of inaccessible web apps.

Janina: This checklist should draw the attention on problem cases, so they can fix them.

- Technology does not allow blinking or flashing of content, or provides a feature for users to quickly turn it off or permanently disable it: n/a

- It is possible to make navigation order correspond to the visual presentation: n/a

Michael: So there was one checkpoint that needs rephrasing.

Cat: If technology provides author control over color: n/as
... If technology provides features to accept user input: n/a
... If technology provides user interaction features: n/a
... If technology defines document semantics: n/a
... If technology provides time-based visual media (n/a)
... If technology provides audio: n/a
... If technology allows time limits: n/a
... If technology allows text content: n/a
... If technology creates objects that don't have an inherent text representation: n/a
... If technology provides content fallback mechanisms, whether text or other formats: n/a
... If technology provides visual graphics: n/a
... If technology provides internationalization support: n/a
... If technology defines accessible alternative features: n/a
... If technology provides content directly for end-users: n/a
... If technology defines an API: n/a

Michael: So there was only one cat applicable. We should add short explanations for categories so that spec authors can quickly assess whether they are applicable or not.

<MichaelC> Web Assembly Core

Abstract: This document describes version 1.0 of the core WebAssembly standard, a safe, portable, low-level code format designed for efficient execution and compact representation.

Michael: It allows Web programming on a lower level than JS.
... There is a group that would like the entire Web to be maintained in such a language.
... Probably has nothing in it for user interface. But could be used to create a UI.
... Could generate a UI directly in the browser, bypassing HTML.

Janina: I can see reasons for this language, but also a lot of potential to break things.

Cat: If technology allows visual rendering of content

Michael: Maybe add a category of generating an own UI.

Janina: Another group could use this spec and use it to fast generate a UI for games.

Michael: Probably the group would say "no" to allowing rendering of content. Because it is not specifically designed for this.

Gottfried: Creating a UI would require a library with widgets and so.

Michael: This is only the core spec.

Michael looking for other WebAssembly specs, but not finding on their home page.

Michael: There must be a way of generating UI elements.

- There is a defined way for a non-visual rendering to be created

Michael: If things can happen by technology, but don't happen by default... There should be a warning in the spec.

Mat: It does not describe any APIs, and no relation to an a11y API. Probably nothing is applicable here.

Michael: Export interface - broken links.
... External values: broken link.

Janina: Could you use this to build a real fast screenreader?

Michael: I assume so.
... Separate area of defining APIs for common hardware features.
... WebAssembly does not have accessibility issues, but dependencies of it do, e.g. hardware. How could be come to this conclusion from using the checklist?
... Would the spec authors conclude form the categories that they don't apply? Can we help them to come up with answers?

Mat: This is an edge case.

Cat: If technology provides content directly for end-users

- Content can be encoded in a manner that allows machine transformation into accessible output

Michael: If the spec authors had used this checklist, would they have seen that?

Gottfried: I think that WebAssembly has no applicability here. Only if this spec defines input and output to the user, then it is applicable.
... We cannot require spec authors to include notes for other spec authors regarding a11y.

Michael: When the WebAssembly wg looks at this spec list, how can they quickly find out that it does not apply.

Gottfried: Foreword that clarifies that only if the technology enables input and output, then it applies.
... If there were use cases, we could make it dependent on them.

Michael: I am increasingly saying that there should be use cases for every spec.
... Maybe at some point we could make it a duty for spec authors.

Gottfried: We could ask them to come up with use cases - even informally.

Mat: This is a programming language that could potentially be used for almost anything. But the parts in this spec have nothing to do with generating content or accepting input.
... But that does not mean that somebody couldn't use this technology and using APIs to generate content.

Michael: They need to come to this conclusion quickly without wasting time.
... Foreword is a good idea.

Mat: "Does your spec specify how your technology can be used to generate user interfaces..."

Janina: Can it be used in unintended ways to generate a UI?

Michael: The HTTP protocol indirectly affects the user interface.
... Output and input.
... Can be unintentionally.

Mat: Taking the point of view of a person not knowing anything about a11y.

Janina: HTTP does not allow transforming content.

Gottfried: "Your technology applies, if it either interfaces to a user, or extends or limits another technology interfacing to the user"

Michael: Unintended use should be included.
... In case of WebAssembly they do not intend user interfaces, but allow it.
... They are not creating a spec to do that, but it is a consequence of the technology they are creating.
... If CSS hides stuff from APIs, that's a problem.

Gottfried: Encourage to make use cases, and check them against checklist.

Michael: We could look at their checklist, and either approve or ask for changes.
... We should also use our checklist, and provide comments to them along the checklist.

Gottfried: Like the idea of using this checklist. Should be based on use cases.

Michael: Some groups publish use cases well ahead of the specs.
... We should go through yet another spec with the checklist. Maybe HTML?

(break until 10:30am)

Now checking https://www.w3.org/TR/html52/

Cat: If technology allows visual rendering of content: YES

- There is a defined way for a non-visual rendering to be created: YES

There is figures, headings...

Michael: Does it need to say "... for all objects"?
... They might fail to see that not all things have a way of non-visual rending.

Gottfried: It should say: "For every visual object, is there a way...?"

- Content can be resized: YES

- Luminosity and hue contrast can adapt to user requirements: YES, though not defined by HTML

Michael: it would be a pass because the technology allows this

Mat: I would say no, because the spec does not describe this. The checklist is for the spec, not for the entire technology.

Michael: We need to reword specific to the spec, not the technology.

- Text presentation attributes can be changed: YES, either CSS or browser.

- Visual presentation of pointers and cursors can be adjusted: Yes, CSS or browser.

- Changing content presentation does not render it unreadable?

Mat: Not applicable.

- Technology does not allow blinking or flashing of content, or provides a feature for users to quickly turn it off or permanently disable it.

Michael: <blink> is removed, so now a pass.

- It is possible to make navigation order correspond to the visual presentation?

Michael: In HTML, unmodified by CSS, it is a pass.
... But don't do crazy layouting.
... In the case of layout table, HTML is responsible.
... Now with CSS, layout tables are less common.
... Should the spec prevent the making of wrong navigation order?

Janina: I would not say anything strong than discouragement.

Michael: Maybe there should be a checklist item about an accessibility impact statement.
... It is becoming common for specs to have a security and privacy impact statement. We would like to have something like that for accessibility.
... "It is possible for authors to do things that are bad for a11y. Please be aware of this."
... E.g. "Layout tables can create renderings that are difficult to navigate. Please be careful when you design layouts in this way."

- If technology provides author control over color?

Michael: Let's assume that it has color attributes.

- There is a mechanism for users to override colors of text and user interface components?

Michael: User agent feature rather than spec feature.

Mat: Something like "allow users to overwrite colors".

Michael: User agents should allow this.
... Do we need this in the checklist? "Where the technology doesn't provide a feature an a11y requirement as defined either the checklist or WCAG, it specifies where it does expect that feature to be addressed."
... HTML would say: "We don't provide a mechanism to modify colors, but we expect browsers to do so."

Janina: This is under the control of the OS.

Mat: Web content respecting the OS settings - there is no way to do this intelligently because as web author you don't know about this.

Michael: That's why we have the AG now.

Mat: In horizontal review, should this be part of the review?

Michael: We need a version of this checkpoint with: "There should be a way of users changing colors."
... If they decline to facilitate a feature, then they should say where they expect that feature.
... We need a wording that leads to a discussion among technologies.
... The W3C director may - in a few years - require the checklist for every technology to be developed.
... He may ask for an explanation for a failure.
... So we need a mechanism to overwrite in the checklist.

- There is a feature for authors to define semantically available "color classes" that users can easily map to custom colors, and give preference to this vs. coloring objects individually?

Michael: Should probably considered an optional feature.

Janina: Maybe across applications?

Michael: Mapping to OS colors possible.
... without having the user to know about technical specs.
... We should still recommend this.

Mat: Would like to see an example.

Michael: We can provide an example here. E.g. CSS system colors, but there are newer ones as well.
... In the introduction: It can be acceptable for things that are not done if other requirements are met.

- There is a feature for users to choose color schemata that work for them?

Michael: Different from previous because authors provide for color swaps - on authoring side. Maybe it goes to far...

Gottfried: If multiple technologies are involved, whose job is it to check for all use cases for a11y?

Michael: It should be our job as APA.
... We need a comprehensive list of what makes an accessible technology. We would do a wide review on technologies.
... The checklist is a tool to help groups meet the horizontal review reqs, and to help us for giving advice.
... I cannot imagine us forcing the groups to provide for all checkpoints all the time.

Gottfried: So the groups should only look at their own specs, and we do the interplay of multiple technologies?

Michael: A group like HTML should also be thinking about CSS.

Gottfried: There are two ways of checking: (1) Focus on single spec with this checklist. (2) Set of technologies, requiring a11y use cases.
... A set of use cases could be developed as a student project.

Michael: I hope that the checklist is helpful for (1) and (2).
... But we may need some more wording on this.

CAT: If technology provides features to accept user input
... If technology provides user interaction features
... If technology defines document semantics

Michael: provide the features that HTML provides.

CAT: If technology provides content fallback mechanisms, whether text or other formats

- Content can explicitly indicate when author declined to provide alternative content

Michael: This is about knowing when the alternative text is not meaningful.
... Could be done by authoring tools.
... Technologies do not need to meet all checkpoints, but should consider them.

CAT: If technology defines an API

Michael: A lot of specs would simply ignore this category. Is this wording useful?

Janina: Yes, there should be this section.
... I would like to walk this with an API spec.
... We adjourn for now, and resume at 1pm.

<Irfan> scribe: Irfan

https://github.com/w3c/apa/issues/9

knowledge Domain Accessibility

janina: we need a better way for publish
... expecting several different profiles. STEM and biology has so many different ways of symbology

<Gottfried> present janina

arno: when we think about maths, we talk about formula and equations but there is more.. like functional dialgrams. we can talk about musical notation. we can find more generalization.

janina: need to find some example that commonly done in ancient language.

gottfried: biblehub.com
... floccinaucinihilipilification is an example. you could break it and then pronounce.

judy: this is not a knowledge domain problem but a linguistic problem
... dont understand why would you be taking script issue in knowledge domain?

janina: this is linear example of missing technology
... if i want to read this kind of stuff then I need to move to the content specific approach. this is very similar to music.

judy: you can pause anytime and study any word just like in musical symbol representation

gottfried: it involved synchronization between inter linear content which is very similar to music.

janina: agrees

arno: math is using weird symbol and if you are new comer and have no idea how to say things.

judy: such diverse things. I am trying to talk with Mike about it. will check with him again.

gottfried: its complex. may be we should really approach this piece by piece

janina: core problem that browser and AT people will never do this.

gottfried: visual presentation has so many ways of representing meaning.
... have no concept of other modalities

janina: we want semantic in relation and have no way to do that.

gottfried: we could do that as a table.. that should be okay. its two dimensional
... you could do it like headings, row headings and just number them through to navigate
... if we do measures of music and then we navigate from measure to measure navigation table cells.

janina: music problem is solved. there is a separate group working on it.

gottfried: can a blind person navigate it?

janina: you translate it to sound and notation for braille display.
... if you are reading braille music then you need to memorize it and then play

gottfried: AT does not have enough power to come up with single solution for every domain. we need to come up with an approach with a semantical approach but AT may not support this.
... someway similar to ARIA
... punctual additional information. from a scientific approach its better to come up with additional approach but its not possible to provide the ways of structuring information.

janina: implication is that we do not have sources to explore more.

gottfried: AI community has similar problem. such as helping to transform the formula. they have some ways to represent the formula and they should have the same problem. I dislike the idea that we as accessibility community needs to come up with a solution because it is much more than accessibility

arno: we have proposal that is being deployed to present abstractly math formula.
... its very convenient starting point for abstract presentation.

gottfried: we need to define like how to navigate math formula, key tables, and for the support of AT we need to come up with code library that could be easily integrate with

arno: when you look at a complex equation for example fraction, you want to be able to have some way to representing it. for authoring it can be done by authoring tool.

gottfried: are you talking about SVG?

arno: it could be SVG but could be HTML or mathML
... in maths, often time you would not be able to specify the braille output.

gottfried: we would have to extend the aria model. you may have multiple aria label depending upon the language. this is tricky.

ian: the benefits go beyond accessibility tree.
... it is just personalization. if we go to aria route than we are cutting of some benefits.

janina: its true that aria has pretty much ralated to screen reader users.
... we need to have group to agree for aria

mark: take back in time to smile.

digital talking books had interesting idea for alternatives within content and content selection.

mark: it was extensible model.
... if you are trying to bring a new mark-up than its gonna be non-starter

ian: personalization choice may be the language specific.
... you need to indicate which part of content you want to personalize.

mark: i will let the end user or AT technology use that attribute value to define the personalization.

arno: often time given equations read differently in England and us. they would want what their student want to hear. or level of the student that might be important when you read something in more explicit way. in this case different variable output we need.

mark: at ETS for a student of 4th grade and student of college is different approach of rendering the content.

ian: if you are a a low vision and not using screen reader, you may be benefitted by long description. we cant make people to click on every piece of information.

mark: we provide some prototype of web component called aria alts. it was a web component that you could draft some kind of web content. it was programmatically scripted by javascript
... we we keep thinking about media or content authorization, personalization is the key

ian: do we have any take away form this for next discussion.
... what do we want to take out from this conversation.

janina: we need more information for publishing. they would like to hear more about it.
... what we need, more than just accessibility
... we also need earlier than later widening the discussion
... those are the topics to discuss it in future discussion
... APA issue 9 is github
... one way to work on it

Pronunciation Demo

<janina> scribe: janina

mh: showing a tool for exploring the use of ssml
... On Apple it maps to osx pronunciation

jd: Notes the spans defined must not be pruned from the a11y tree

gz: Asks why?

jd: In someaapi may not have separate object
... For the ssml to be communicated, you need an object to receive that data.
... You wouldn't examine the tet on the off-chance,
... So create an a11y object span and the at will pick it up
... Will put tab index on it
... Anyone implementing needs to expose an accessible object, then the ssml

gz: This is really extending the a11y tree
... We're probably going to een more of that for Knowledge Domain support

[discussion of architectural approaches]

jd: Notes things belong in the aapi independent of aria

gz: Expecting not only how to pronounce the cehm formula, but we'll pick up ways to nav the formula

mh: believe it's a simpler problem for read aloud tools
... screen readers are the hard problem

jd: don't think it's that hard. speech-dispatcher already supports ssml

mh: should also help interface like google home and alexa scraping content from web pages

[discussion of vendor interest, and of TF steps]

jd: suggests an object attribute "ssml"
... suggest this for atk and for ia2
... then ask osx and ms for their appings

ia: asks after proper way to write up use cases

mc: no specific format
... suggest looking at specs that do similar things

gz: looks like an elegant solution

mh: well, it solves the problem

mc: Issue that we're not chartered for this ormative deliverable

mh: would like to do in a year

[demo is using jason with ssml properties]

tess: Asks why not css speech?

mh: doesn't do everything necessary, especially pronunciation
... Notes that the W3C pls spec also considered
... notes ssml native on Windows 10, also Google on soe speech engines
... Apple has its own markup, but this should map there

trackbot, start minutes

<trackbot> Sorry, janina, I don't understand 'trackbot, start minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

trackbot, startmeeting

<trackbot> Sorry, janina, I don't understand 'trackbot, startmeeting'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

[discussion of viability of the jason approach]

tess: thinking analogy to ruby elements
... enough demand to incorporate it
... good example of why the data attrib is available
... asks whether there's a doc that lays out what's being used currently?

mh: Gathered, but not yet put together into a single doc. Soon.

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)

Succeeded: s/=/?/
Present: tink (Léonie) Gottfried MichaelC janina mck mrobinson Irfan judy Roy IanPouncey mark tess
Found Scribe: Gottfried
Inferring ScribeNick: Gottfried
Found Scribe: Irfan
Inferring ScribeNick: Irfan
Found Scribe: janina
Inferring ScribeNick: janina
Scribes: Gottfried, Irfan, janina
ScribeNicks: Gottfried, Irfan, janina

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