<Gottfried> scribe: Gottfried
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
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
<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.)[End of scribe.perl diagnostic output]