See also: IRC log
<johanneswilm> I don't think I received the meeting webex password
<janina> One moment, Johannes ...
<janina> Gottfried, not sure what to advise. Do you have sip?
<scribe> scribe: Gottfried
Michael: WCAG 2.1 wide review published yesterday
janina: We are invited to do a horizontal review
janina: Johannes gave us some
questions a while ago - we need to better understand them
... Do we have an issue tracking page for input events?
johanneswilm: Under w3c, input events
<MichaelC> https://github.com/w3c/input-events
janina: Leonie talked to the JAWS
people.
... Walk through Johannes' questions?
<MichaelC> https://lists.w3.org/Archives/Public/public-apa/2017Mar/0013.html
> 1. From an accessibility perspective the following would be valuable:
> - A notification to ATs that functions like text insertions were completed
> so that positive reinforcement could be provided to the user.
johanneswilm: JavaScript gets a
notification, can react. At this stage, any DOM modification
should be done.
... Your 2nd point: Create your own events. There are two ways
for this.
... JavaScript can make events. If interacting through some
other API, it depends on the browser.
... We have made a list of all editing actions that any of the
browsers allow.
... And what would be consistent with what's already existing
on the browsers.
... No browser supports all editing actions today.
Leonie: I spoke to Glen Gordon,
original developer for JAWS on Windows.
... Notifications would need to be configurable by the
user.
... No way to provide out-of-band information in a
locale-independent fashion. Windows API does not support this
currently.
... We would need to talk to the platform API people.
<johanneswilm> +q
johanneswilm: If the user makes an edit action, Javascript gets notified, and can either let the browser do the action, or do it itself.
<johanneswilm> anyone in the call?
johanneswilm: By default, there
is no Javascript code to catch this - needs to be coded.
... Typically, the application wants to be notified about all
editing actions of the user.
tink: There is no way for a meaningful information to record on the DOM tree.
johanneswilm: It is not clear by
looking at the DOM changes.
... We would need this before the input event is handled.
... Also, the application may want to ignore some edit actions
(e.g. bold).
tink: As far as i know, these
edit events would not always occur on screenreaders.
... Maybe i need to look at how screenreader do this in
Word.
Joanmarie: When i press at a
toolbar button, i get a text attribute change event.
... So if it notifies me about text made bold, i can assume it
was the bold button.
... The user agent should be able to identify the appropriate
text attribute that was changed
janina: The specific use case is
when we are editing content through browsers.
... Word-processing style edits
<johanneswilm> +q
Joanmarie: Looking at the list of
edit actions, all could be communicated by a user agent through
my platform.
... Don't know how one would go from the input event spec to
make this happen - but should not be difficult.
johanneswilm: List of actions is
fairly long because different browsers support different
events.
... E.g. Safari supports changing text color. This creates
problems between editors and users - because nothing
happens.
... List does not contain all actions that would be
desirable.
... Only actions will be executed if Javascript handles
it.
... Sometimes, there is no input event for special actions,
e.g. "insert citation".
... Making a JS editor is a multi-year effort. They could add
information for screenreaders.
janina: Which year are we in?
johanneswilm: I have been
actively involved since about 2014/15. Shipped recently for two
browers.
... There is a fairly small number for building editors,
probably 20-30.
janina: Next steps?
Joanmarie: Safari should be okay.
But i don't know what Windows has.
... Adding types for edit actions in Webkit-TGK.
johanneswilm: Looking at Word
processors, are there things that browsers currently don't
support, but we need them?
... Full-day meeting on text editing at TPAC.
janina: Can we have time together?
johanneswilm: yes
tink: Tuesday for editing tf
johanneswilm: I can present your ideas to the meeting. But you are welcome to join the meeting and present yourself.
janina: Most of us will be at TPAC in San Francisco. So we should make progress on this.
Joanmarie: I can look into Webkit and then tell what could be done. And maybe make a demo of what could be done.
tink: Would be extremely helpful.
johanneswilm: In a demo world, all events will be executed. But if you use the actual editors, they cancel about 75% of the events via Javascript.
janina: We might need to negotiate about this.
johanneswilm: tinyMCE, CKeditor, etc.
<johanneswilm> prosemirror
<johanneswilm> substance.io
johanneswilm: tinyMCE and CKeditor are used by Wordpress and typo3.
janina: We should think in terms
of non-screenreader AT. No idea yet about possible
issues.
... Think about use cases outside screenreaders.
Gottfried: What about keyboard users without screenreaders?
janina: Key bindings as an alternative for pressing buttons.
tink: Worth picking up at TPAC.
janina: Thank you, Johannes, for joining us.
janina: I get an action on WCAG
2.1.
...
<MichaelC> ACTION: Janina to review WCAG 2.1 https://www.w3.org/TR/WCAG21/ - due 3 Oct [recorded in http://www.w3.org/2017/09/13-apa-minutes.html#action01]
<trackbot> Created ACTION-2144 - Review wcag 2.1 https://www.w3.org/tr/wcag21/ [on Janina Sajka - due 2017-10-03].
janina: who else?
MichaelC: Sent horizontal review requests to others. In APA, we should look at usefulness for accessibility, coherence, conflicts with other specs, conflicts with other things that WCAG does not provide a hook for.
<MichaelC> WCAG 2.1
janina: Make a list of things that should be added in the future.
<MichaelC> action-2144: https://www.w3.org/WAI/APA/wiki/Web_Content_Accessibility_Guidelines_(WCAG)_2.1
<trackbot> Notes added to action-2144 Review wcag 2.1 https://www.w3.org/tr/wcag21/.
<MichaelC> Long Tasks API 1
This document defines an API that web page authors can use to detect presence of “long tasks” that monopolize the UI thread for extended periods of time and block other critical tasks from being executed - e.g. reacting to user input.
MichaelC: Do we need to comment
on this?
... My guess is that it does what it would need to do for us -
but not really sure.
... It's an algorithmic spec, hard to see what it does.
Joanmarie: Could be some relevance for AT related events. Can we come back to it?
janina: Come back in Jan?
<MichaelC> ACTION: cooper to ping review on Long Tasks API 1 - due 4 months [recorded in http://www.w3.org/2017/09/13-apa-minutes.html#action02]
<trackbot> Created ACTION-2145 - Ping review on long tasks api 1 [on Michael Cooper - due 2018-01-13].
<MichaelC> Paint Timing 1
This document defines an API that can be used to capture a series of key moments (First Paint, First Contentful Paint) during pageload which developers care about.
MichaelC: Another algorithmic spec. Can't tell what it does. My guess is we are not interested, but could be wrong.
janina: Agree.
(no objections)
MichaelC: Shadow DOM needs attention.
janina: Looking for Shane.
Joanmarie: I will email him about this.
<chaals> [Shadow DOM probably does need attention...]
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 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/Glyn Gordan/Glen Gordon/ Succeeded: s/them./them?/ Succeeded: s/a11y/AT/ Default Present: Johannes, Wilm, JohannesWilm, Joanmarie_Diggs, Gottfried, janina, tink, MichaelC Present: Johannes Wilm JohannesWilm Joanmarie_Diggs Gottfried janina tink MichaelC Regrets: Chaals MichielBijl Ian Found Scribe: Gottfried Inferring ScribeNick: Gottfried Found Date: 13 Sep 2017 Guessing minutes URL: http://www.w3.org/2017/09/13-apa-minutes.html People with action items: cooper janina[End of scribe.perl diagnostic output]