- From: Gottfried Zimmermann \(Lists\) <zimmermann@accesstechnologiesgroup.com>
- Date: Tue, 23 Oct 2018 11:26:56 +0200
- To: "'W3C WAI Accessible Platform Architectures'" <public-apa@w3.org>
This is the session on FAST – Framework for accessible specification of
technologies.
HTML format: https://www.w3.org/2018/10/23-apa-minutes.html
Text format: See below.
Best regards,
Gottfried
___________________________________________________
Prof. Dr. Gottfried Zimmermann
Access Technologies Group, Germany
___________________________________________________
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SV_MEETING_TITLE
23 Oct 2018
Attendees
Present
tink, (Léonie), Gottfried, MichaelC, janina, mck,
mrobinson
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Gottfried
Contents
* [2]Topics
1. [3]FAST - Framework for accessible specification of
technologies
* [4]Summary of Action Items
* [5]Summary of Resolutions
__________________________________________________________
<scribe> scribe: Gottfried
FAST - Framework for accessible specification of technologies
FAST checklist (draft):
[6]http://w3c.github.io/apa/fast/checklist
[6] http://w3c.github.io/apa/fast/checklist
Picking a test spec: CSS Overflow Module
<MichaelC> [7]http://w3c.github.io/apa/fast/checklist
[7] http://w3c.github.io/apa/fast/checklist
[8]https://www.w3.org/TR/css-overflow-4/
[8] 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> [9]Web Assembly Core
[9] https://www.w3.org/TR/wasm-core-1/
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 [10]https://www.w3.org/TR/html52/
[10] 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.
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [11]scribe.perl version 1.154 ([12]CVS log)
$Date: 2018/10/23 09:23:22 $
__________________________________________________________
[11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[12] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56
Check for newer version at [13]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[13] 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
Found Scribe: Gottfried
Inferring ScribeNick: Gottfried
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 [14]scribe.perl diagnostic output]
[14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Tuesday, 23 October 2018 09:27:23 UTC