<jongund> scribe: jongund
JN: The background on role parity
... 1) Whether things are allowed to be named
... arial-labelledby and aria-label are global, but not evenrything needs them
... 1) DIV and SPAN, generic roles
<melanierichards> Melanie Richards present+
JN: What is in the HTML AAM today, if they have default styling ...
<scribe> scribe: jongund
<Glen_> https://irc.w3.org
MK: Youare trying to summarize where we are
JN: Into the prohibition on labeling
... The generic role is the easy role, but the things on top of it are more complex
<jamesn> James Nurthen https://github.com/w3c/aria/wiki/Generic-Role-End-to-End
JC: AAM issues would follow ....
JN: The current div mapping, and the span mapping is completely different, we need to find something that works for both
JD: When spans to not need to create accessible object all the time,
<jamesn> James Nurthen q+ to share the sheet I was working on
JD: When the span disappears and I have something16:43:16 <jamesn> RRSAgent, make log world
... When you expose an accessible object, and it has a tabindex it needs to be mapped
<jamesn> https://docs.google.com/spreadsheets/d/1i0D6FYBnYEYsdfilK0oiooI-f7PF2wXPCwMV7E8jJdk/edit?usp=sharing
MK: When something is bolded thought he span
JD: When someone puts a title on a span it has to be mapped for people to get the accessible description
... If you are using the newest version of ATK you use the STATIC, old the TEXT role
MK: In these limited conditions it maps to STATIC
JD: There needs to be language, if its mapped...
... If it si mapped it should use role STATIC
... The B element is not exposed, ...
<Zakim> jamesn, you wanted to share the sheet I was working on
JC: I realize that that might be something that gets a label
... We could have some user agent guidelines to ignore name on generics
... I want to talk about implementation details, NOTE: drawing on white board
... I am not sure if it applies to other browsers
... If you have a MAIN element that contains a DIV and the DIV contains an HEading and the H! has a SPAN
... Accessibility APIS start with the rendering tree, not the DOM tree
... Issues like CSS rendered content are included in the rendering tree, not DOM tree
MK: Where are the before and after elements?
JC: on the H1 element
... I drew it inside the headings, but should be after
... The main point it the rendering tree is the baissis for creating the accessibility tree
... So the DIV node would not be part of the Accessibilty tree
... If a SPAN is added with no additional styling they will not be part of the rendering tree, but if you style one of the SPANs then it becomes part of the accessibility tree
Harris: What if you add an aria-label to the SPAN, what happens?
JC: This is one of these undefined mappings
JN: Is it useful to give the SPAN an accessible name
JC: Does this help?
JD: There are other DIV like things that AT don't know
JC: Another example is a A element with a container DIV, there effectively get additional links in the rendering tree
... You get a link with FOO, and then another link with BAR and then another DIV bar, but ehy are all the same link (from A element container)
JD: This is what I was thinking of
JC: We call these element continuations
JN: In the implementation do ATs get three links?
JD: on my platform you would get one link, but there would be three parts to the link
MK: THey have to be ....
JC: This is why VO stops at certain points
MK: Some screen readers would be three separate lines for FOO, BAR and BAR and other ATs it would be FOOBARBAR as one line
... If you SPANs you see all of them as one line
... If I wanted to make that link accessible, we would figure out a way to giev authors to say this is all one line of text, not three separate lines of text
... Text separation values are: style, line break, none, paragraph and space
JN: Style is the default
MK: We don't want to break existing implementations
... I only want it on child elements
... You could put is on the DIV with bar
... On the DIV none none, space space....
JC: I was against separate role for each generic, these are implemented the same except for the style
JN: If you only have one role that is a problem
JC: ALl of these style properties get exposed tot he accessibility tree, including position changes
... We only need these to be generic, since we have the style properties
... Has written some CSS selectors and properties on white board
JD: You were apposed to a generic for strong
... we looked at the HTML we have STRONG and EMPHASIS
JC: I am not sure if any implementations expose the semantics
JD: For role parity we need to provide the AT the same information
JN: The B is not meant to express semantics
MK: What if don't map it differently, then you would not be able to tell the difference between using STRONG and a style of bold
JC: I have never had a user ask me for being able to tell the difference
MK: Let's take a test where the words in bold represents a definition
JC: It seems more academic discussion
MK: If we are saying there no way to identify emphasize text?
JC: Are authors really using the elements to indicate emphasis
GG: As a screen reader developer always going to look at styles to figure out semantics
JC: In added a STRONG role, it is harmless
GG: Is that more broadly
MK: As an author if I create bold text and do not use a STRONG role, but use a style, a screen reader would not be able to tell the difference?
JC: One of the general rules we have is that provide the same information as the sighted user, in this case the sighted user can not tell the difference
GG: The STRONG role provides more information to the screen reader in this case, and provide more value to the user
MK: You are doing what you are doing, because authors often do not use the STRONG element consistently
JC: That is what we have done for a long as I remember
JN: We are taling about BOLD and STORNG now which is different from GENERIC role
<carmacleod> https://github.com/w3c/aria/pull/967
JN: I put together previously, what if we made aria-labelledby and aria-label not global
JC: Sound check?
JN: I added it to..... list ....
... The following roles not longer have access name alert, ..... list of roles ....
... This would mean that it would be an author error to use on certain roles
JC: I missed the precursor discussions, ....
JN: My list is not toally accurate
MK: There are some specific uses of label that aaron had
... This is an alternative to created something that was not labellable?
... What we do in the accname spec
... Ideally in my mind that accname, if you did aria-label it would be ignored
JN: Validators can pick up the case
MK: the validation part is not important to me, what browser do will effect SR
JC: JN is saying that browsers would not map
MK: We would update accnam to not compute
JN: We would take out of the spec the authoring row
MK: The row would not be in the spec
... There are already some ....
JN: There is an additional fallout, can things not be describable
... There are other authoring issues, but they are already broken anyway
MK: Presentation role has many edge cases
JD: RS made changes
MK: If we have a way to leave things out
JD: If you can't name this it will be ignored
JN: Possibility leaving them global and have exceptions
JD: There is a "content" role option, creating a sibling role of section
MK: I think that is the same thing as saying labeling options is not global
JN: There are two possibilities for the naming:
... What feels nicer? Leave global with role exceptions or remove form certain roles
JC: ARIA spec specific identifies role that cannot have a name, so that the spec does hold back role development
MK: Even if you made them none global, if it doesn't have an ARIA semantic, you wouldn't be able to label it
JC: We wouldn't have a way to say if a new role has it or does not have it
... There are VR being exposed, like canvas
... We could map to a pointless role like CANVAS
... Its disallowed except on these specific roels
JD: Can you give me an example
MK: HTML provides a way to label elements
JC: You can't labeling anything except for form controls in HTML
MK: HTML provides a way to give an accessible name, so HTML should provide a way to...
JC: What about DPUB and other ..
... Saying those other specs need to update there expections
MK: If a global property, except when it is not
... If you have a role that has aria-label in the supported property, but no name is not allowed
JD: Are we concerned about not ARIA roles?
JC: I am concerned about future web features
MK: You want aria-label available to new features
JD: Since we do not have role parity, there are already AAM mappings that we do not control
... The new elements can say they support aria-labelled
MR: I kind of agree, I don't think HTML will bloack me form doing anything
JC: It is not that ARIA is blocking HTML
... If ARIA says only these things that will allow labelling, then implementations may not support new features that need it
MK: We don't want conflicts with HTML like LI can have label and role=listitem cannot have a label
JC: To me it more like this is allowed on video
... in SVG if they have circle ...
MK: If we leave it ambigious...
JC: I want that primitive available to new roles
JN: We need something that says everything has them, except these roles
MK: It needs to be in the sections about labeling, 4 sections of ARIA spec
JN: We should only do a hadful, where there is not controversy
BG: This will also effect the presentation role?
... When you put label on something on something with role=presentation
MK: We would need to change role=presentation, label would not be on presentation, would not get ignored, you can label something ...
HS: How is ARIA been versioned?
<Zakim> jcraig, you wanted to mention labels could be limited to apply to ~"any element with an implicit or explicit role"
HS: Seems this will break some things, should this be version 2.0
JC: In general every version of ARIA has broken something
<jcraig> (mostly small breakage)
MK: ANyone who is using label on any of these things, they are already not interoperable
JN: SOme people only design for a certain borwser and AT
JC: Matt made a good point, this is not based on specs, but on just what browser do
MC: We need to call out for wide review, sometimes unspecific features become widely used
JC: When I was more involved, I complained about role parity, I want to make sure the group needs this for role parity
JD: We need this for generic roles
JN: Everytime we bring up a new role this is part of the discussion
... Can we get through text separation before break?
MK: We are looking at children, as soon as we start talking about children
... If you put aria-separation on a container with lots of descendants, it only effect the text nodes of the childern
JC: I have the same concerns
MK: It only effects the text nodes of the children
GG: Can't there be conflicits
... harris is drawing on the white board ...
HS: DIV with a SPAN, BUTTON and SPAN as children and then there is a DIV sibling with the same SPAN, BUTTON and SPAN as the first
JC: Where does the aria-textseparation go?
MK: If you get rid of the span and just have text nodes then they would go on the DIV
... Can we put words in these things
... group editing of example on white board ....
... The separation is to effect the pronunciation of words
JN: If I have DIVs and I want no text separation, I would need to put then om every single DIV
JC: If this element allows document flow, then you my want to specify separation
JD: We are currently just shoving text in to the Accessibility API, where will these insert spaces go?
JC: Who processes this text?
JD: it is imaginary text separating two DIVs
MK: The author did not code a space, but the author is using CSS layout to move the letters all over the screen
... You have to have someway for element separated text to be spoken as one word
JC: You are trying to get he accessibility API to believe it is CSS inline block layout
JN: We do have the space, wouldn't that be easier to do
... I do need a place to remove spaces, I question the need to add spaces
MK: The jumbled letter example
... text separation is what we want, I heard the implementation issues
<Glen> JN: background of issue 899, NC asked for better way to name article role.
<HarrisSchneiderman> scribe: HarrisSchneiderman
<jcraig> q
jongund: We've recently added accName calculation techniques. Low hanging fruit example -- heading: A container referencing heading for name
... It can't hurt to have an accName on a "main" for example
... form is only a landmark if it has an accessible name
mck: can you describe what is in your legend PR?
jongund: legend is basically for the group/radiogroup roles. if you have an element with role=legend (or the <legend /> tag) as a descendant of that group/radiogroup then it'd become the accessible name of that group
<jongund> https://github.com/w3c/aria/issues/899
jcraig: a bug filed on facebook - I rotor'd to articles and started flipping through them. VO speaks "article article article" etc...
... nothing useful was spoken
... heading is a similar case as legend.
... the web is messy - there are going to be times in which people use the right tag but there still isn't a great way to detect this
... in the cases in which the author hasn't done the right thing.
... take a dialog with a paragraph of text and then some button controls
the dialog's name would be the paragraph
jcraig: using heuristics, we can determine the accName
jamesn: this could be in an "Error correction" section for authoring errors
... we could have "If something is unlabelled, that requires an accName...these are techniques in which the UA could calculate it: ..."
jongund: I don't think the heading example should be considered an authoring error
jcraig: the dialog with paragraph and button is a good example of authoring errors
<carmacleod> Authors SHOULD provide a dialog label, which can be done with the aria-label or aria-labelledby attribute.
joanie: a screen reader could decide that an article with no heading should have a name
jcraig: VoiceOver doesn't really know much about the web, it just knows what webkit does
... we could have webkit expose a "possible label" (fallback)
joanie: I like the idea of finding a heading
<jamesn> "Accessible Name Required: True" for dialog
joanie: in the case of an article with a bunch of paragraphs and no name...Look for a heading - that's the name
... if there isn't a heading, then the first text block element is expose as if aria-describedby is pointing to that element (assuming aria-describedby isn't provided)
mck: I wonder, even with the heading case, if we put this in the spec..."A heading is allowed to label an ancestor container" is what we'd be saying
... Basically, a heading can do what a legend does in a fieldset
... do we put a ton of rules in here?
... what if <p /> <p /> and then a heading?
... Where do you stop looking for a heading?
... We're basically saying then it'd be the first descendant heading
... this is better than no label
... this seems like it'd have a lot of risk potential
... The rotor could completely misidentify the article
... we could be losing an articles meaning
... they might think that what they're looking for isn't there
<carmacleod> HTML says: "The first element of heading content in an element of sectioning content represents the heading for that explicit section."
jcraig: this is where heuristics comes into play
... I'm not sure headings should count in the official name calculation definition
jamesn: are you saying this could just be in a fallback section of the spec?
jcraig: web engines are forgiving in that they correct authoring errors
... I feel like this should be up to implementation until we figure it out
jamesn: What if its "the first non-widget / non-interactive element with text"?
joanie: that'd be problematic
jamesn: card layouts are often like this -- the heading is not the first thing in the element
joanie: Articles should have names, right?
jamesn: its not required in the spec
joanie: thats what Im saying - we should make it required in the spec
bgaraventa1979: I've seen templates that use articles as part of the template. The content inside of it is dynamic so its not always known up front
... Do we have to actually specify screen reader behavior?
... take facebook...you scroll through different articles, you could pick what makes sense to be the accName. so does it have to be in the spec?
<jamesn> HTML spec states "Each <article> should be identified, typically by including a heading (<h1>-<h6> element) as a child of the <article> element."
jcraig: there may be a bug with this in implementations
... ideally, I'd like the interoperable behavior to be the same
mck: freedom scientific does a good job trying to guess labels of unlabelled form fields
<jamesn> actually I take that back - it doesn't state that any more
mck: so that kind of fallback functionality in AT seems like something that doesn't have to be in the spec
... it's not in the spirit of the aria world -- we're not going to dictate AT experiences
<jamesn> HTML 5.1 does but WHATWG version does not
jcraig: How would we differentiate the fallbacks vs non-fallbacks?
joanie: the way gecko exposes layout tables is they expose it as a table and expose a layout attribute
... so I consume that as "Is it a table? Nope, gecko doesn't think so"
... ideally this is consistent across user agents
... I'd be ok with somehow knowing that it was a guess or not
bgaraventa1979: feed uses articles and it uses describedby as part of the pattern
jcraig: Presumably in that case, the author knows the right thing to do...we can assume that anytime we get a random description without a label than it is heuristic browser guessing??
joanie: are we not liking the heading idea?
jamesn: in the case of fallback -- they weren't going to get anything useful to begin with...
CurtBellew: to me a bad label is a lot worse than no label
jongund: using a heading is a lot easier than using aria-labelledby
mck: If a browser is going to implement this, then we need some limiting rules...
... "The heading must be the first non..."
... It can't be too far into the article
jamesn: we should look and see how many problems we see in the "real world"
mck: I see on tons of sites, a main with an H1 and then the article is after that
... The label of the article is really far away
... there will often be headings inside of that article
bgaraventa1979: I come across this all the time...on CNN, whenever I try to read something they have a carousel-like thing in which every single image is an article
... Literally just 1 image is the article
... so you get 100s of actual articles on the page
... this makes it very difficult to tell what/where the actual article is
jongund: You wouldn't want to double-up accessible name fallbacks across articles
... We really need to think about nested articles here..
<Zakim> jcraig, you wanted to point out the ability to spider the results we'd need to determine
<jcraig> https://discuss.httparchive.org/t/usage-of-aria-attributes/778
jcraig: here is a list of most common aria roles (Simon Pieters wrote this query to scrape this info)
... its possible we could use one of these services to gather info on articles that include headings within them
<carmacleod> Also "header": The MDN doc says article should have a "heading" child, but the example has a <header> element.
jamesn: We still need to do some investigation on whether we want to include headings in calculating accNames
jcraig: this could be as simple as some suggestion "Implementers should..."
<bgaraventa1979> https://www.cnn.com/2019/04/30/health/mallinckrodt-whistleblower-lawsuit-acthar/index.html
bgaraventa1979: Every single article on the page contains an image and a heading
joanie: some of us have concerns with the headings
... we need to do some research
jcraig: I didn't hear any objections to letting User Agents do some of the guessing / heuristics
jamesn: A question posed is "should an article have to have a label"
<carmacleod> Nested articles might not need a heading? From MDN doc for article:When an <article> element is nested, the inner element represents an article related to the outer element. For example, the comments of a blog post can be <article> elements nested in the <article> representing the blog post.
jamesn: I think we need to find someone to look and see what's out there on the web
... We could maybe ask steve faulkner
... or scott o'hara
mck: this doesn't seem like an aria 1.2 priority
... it's not a clear bug
... If we have other things that we want anyone to work on that are a higher priority...we better make sure this doesn't get in the way of those things
jamesn: I like putting something in a authoring errors section and we can approach this as such
<jcraig> joanie, another example of spider results... this one for instances of the `text` role: https://discuss.httparchive.org/t/pages-with-role-text/809
<joanie> https://github.com/w3c/aria/issues/899#issuecomment-488084625
<Glen> Scribe: glen
<MichaelC_travel> scribe: Glen
<joanie> https://raw.githack.com/w3c/aria/math/index.html#math
<joanie> https://w3c.github.io/aria/#math
JD: What's the purpose of this math role? Just started rewriting that section. Trying to decide if shoul.d or notpersist
<joanie> The primary purpose of the math role is to inform assistive technologies that the content is mathematical in nature and thus may require special presentation, in particular with respect to synthesized speech. More specifically, screen readers and other tools which provide text-to-speech presentation of content SHOULD do the following:
<joanie> prefer full punctuation verbosity to ensure common symbols (e.g. "-") are spoken.
<joanie> prefer mathematical names for symbols (e.g. "minus" rather than "hyphen" or "dash")
<joanie> speak single letters using their character names (e.g. "a" should sound like the "ay" in "say"; "⍺" should be spoken as "alpha" without changing to the Greek synthesizer)
<joanie> The math role also serves as an indication to assistive technologies that the mathematical expression lacks author-provided navigation. Authors wishing to provide their own navigation or exploration within a mathematical expression SHOULD NOT use the math role; instead they SHOULD use a role associated with author-managed focus such as application or tree.
<joanie> Beginning with ARIA 1.2, children presentational is false for the math role. This change was made to be consistent with the existing behavior of the majority of user agents.
JD: Three examples should be one with CSS, one with Graphic and one with SVG
JC: Drawing on board. WebKit will render based on MathML structure. Will convert to Nemeth Braille. Offers sub equation navigation. Can get really complex structures and explore every piece of it.
... Would like attribute to unambiguously represent the contents of the math regardless of what was used to render it
JD: Been doing work to make CSS and SVG more accessible. Can SVG math be made accessible without an explicit text property?
... Peter has been working to expose Nemeth Braille
MK: ARIA-Label-Braille, ARIA-Role-Description-Braimlle
JC: Maybe someone will make assumption that people want Nemeth when they don't. Shouldn't offload decision to page to authors
MK: Essence <DIV role=Math ARIA-Math-Description="long description"> and everything in that is hidden from screen reader
JC: May be broken for low vision users who combine screen reading with zoom where it would be hard to follow along visually with a sub-formula when there's an alternate presentation for the screen reader
MK: Could have Role=math for quadratic equation and used ARIA-Math to hold custom string to be spoken and could then have both attributes on child elements to allow sub expression navigation where the author specified what would be spoken at each level
JD: Maybe ARIA-Math property could be supported on role=Math and optionally on any/all of its descendents.
MR: So many ways to express math. How can we do this in consistent way? With structural approach where could specify strings for each part of equation, seems like we're getting there, but still are missing some semantic info like roles for numerator/denominator
JD: Considering additional ARIA roles for math targetted for ARIA 1.4
... For authors who choose not to use MathML, how can we do better than a single image and allow sub expression navigation
<Zakim> jcraig, you wanted to ask about latex or other other unambiguous math format
JG: Seem to be making up way to use the Math role for people who aren't using MathML
... Are we making the problem worse by having a Math role?
JC: With ARIA-Math attribute, could have unambiguous braille output for math from an image
MK: If we have an ARIA-Latex attribute to be applied to an image, we could specify that the alt tex was using LaTex
JC: Can already do that now with a DIV role=Math and this attribute
<jcraig> Wikipedia Quadratic Equation image includes LaTeX alt="{\displaystyle x={\frac {-b\pm {\sqrt {b^{2}-4ac}}}{2a}}\ \ }"
<jcraig> https://en.wikipedia.org/wiki/Quadratic_formula
GG: On Wikipedia, already make MathML available to screen readers even though for browsers that don't natively support MathML, a graphic is visible
jd: Do we like idea of new property to use with this role?
JC: Shouldn't start out with discussing how to do sub expression navigation because most page authors will be confused
MR: As long as we leave it open to extensions, we should be fine
JD: Some testing environments screen reader want to override presentation so that the screen reader isn't too helpful
JG: Happy not deprecating Math role
JD: Keeping math role, trying to do some of the things that I've put in Github, have a property to expose LaTex on top level element, maybe ASCII math
... Attributes aren't bad if you have a reason to look for them. Can selectively check for these new attributes on elements with role=Math
JN: General consensus that we should improve the Math role
<melanierichards> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Accessibility/VirtualContent/explainer.md
<MichaelC_travel> scribe: MichaelC_travel
mr: worked with Rossen on proposal for virtualized content
^
suggested from Edge team to ARIA WG
use case is a site with lots of content only a portion of which is in the DOM at a moment
e.g., an image gallery
for performance have to load the subset
but AT only knows about DOM
may not know what´s missing
this proposal allows author to express that more content is available in a particular direction
while minimizing fingerprint surface by making it developer-provided not user-requested
proposed attribute ¨aria-virtualcontent¨
with token values block-end, block-start, inline-end, inline-start
when no more content left, set to none or remove attribute
expect it would be on a scroll container
exposed to DOM on scroll events as starting proposal
Example - AT navigating headings, gets to end of list, but sees aria-virtualcontent=¨block-end¨
so send a scroll request, this triggers load of next tranche of content
not suggested for feed role because of collision with other uses
and allows more flexibility about where the additional content is located
ra: this isn´t new conceptually, lots of virtual scrollers exist these days
don´t want to force new patterns for a11y purposes
that works against us
this enables an existing pattern of fetching into DOM
have prototyped on existing content
2 patterns -
on scroller, which has virtual content
there can be a collection of e.g., tables or headings inside
AT knows how many are present that have been fetched
and can navigate to last one loaded
but currently you assume there´s no more
in prototype, if container declared to have virtual content, AT knows it can send a scroll request
which will load if appropriate
then AT gets notification new content loaded, starts to explore
second pattern - can set on the last object in a set to say there´s more that could be loaded in the set
once you get to true end of set, remove attribute or set to none
setting as a property instead of a role
feed role has similar function
and can expand value set of attribute in future
i.e., perhaps know about multiple types of virtual content such as tables, links...
jc: clarify rows as token list?
ra: role attribute generally take token list
to allow fallback roles
but this case is more like multiple simultaneous roles
so better to use property on a single role
gg: how does AT know where new content begins and old content ends if not scrolling 100%
e.g., if I´m navigating headings, I have to wait for script to load what´s next
but it may not have loaded the entire next tranche when we start exploring?
jg: or list
gg: if you go from header 4 to header 5, but first two have scrolled away, how do you know which one to move to
jc: assume browser sorts
mck: do you unrealize or keep?
gg: either way not guaranteed to scroll 100%
mck: take 100 page doc with heading on each page
you start with pages 1 - 3
when you get to 3 and hit h, 1 disappears and you´re on last of 2 - 4
so you´re always on last heading
so you re saying don´t know which one you´re on?
jc: that´s implementation
each UA has a way to say ¨this node was here before¨
AT shouldn´t bypass that
gg: assume focus gone to that thing??
jc: no
if you unrealize content, things could get lost, but not if you just add to it
ra: assume headers 2, 3, 4 in DOM
your scroll request has script load one header and remove one
now you have headers 3, 4, 5
there are 2 questions - how do I know header 5 is in? and how do I know 5 is 5th?
gg: the second is more my concern
ra: so you are concerned you don´t have way of comparing nodes?
gg: depends if they´re constant, or destroyed and recreated
jc: makes sense as a concern
gg: assuming there´s potential for nodes to be recreaed
mck: how about if next heading is 3 pages down, I go to next heading, the intermediate pages are gone
kb: why remove content
mck: when a11y tree gets huge
... screen reader likely to be in reading mode rather than interactive mode
that was an assumption for feed even though not always true
it wasn´t a generalized solution
I like this idea of extending and putting API behind it
<Zakim> jcraig, you wanted to ask about multi-directional scroll loader... could this work on a giant spreadsheet, map, or other grid with unrendered content in four directions....
jc: what if I have a table way down in the doc and I´m navigating among tables
does it load all the intermediate content until getting to the table?
ra: is that a different experience for sighted user?
AT can usually go quicker in this circumstance
jc: how is scrolling in multiple directions supported
like a map, grid, spreadsheet
this seems like something worth incubating in WICG
AOM incubating there, some of which falling into ARIA
could be some back-and-forth
<Zakim> MichaelC_travel, you wanted to mention impact of scroll request via heading navigation request
mc: if scrolling by heading, if lots of content between headings could you miss what´s in between?
mr: AT could come up with ways to address
mck: other implications similar need to sort out
jg: will you need an index of all the navigable objects
jn: don´t know that currently for paragraphs
... don´t know that currently for paragraphs
<Zakim> joanie, you wanted to ask about scrolling to get the next header when there is no next header
@@
jd: say I´ve gotten to page 5 of 100, but there are no more headings
if I load the next tranch and still no more headings, have to reissue scroll command until one turns up?
mr: yes, that´s what we expect
jd: I could go all the way to page 100 without getting one, tedious for user
who now wants to go back to heading 5, long way back
jn: is this different for visual user?
jd: eyeballs are fast
ra: <trying to get a word in edgewise>
this has come up before
one main point is that it´s a similar experience for sighted users
whether you like it or not, this is an established pattern
we just want to make it accessible
this proposal shouldn´t impact structural navigation
this isn´t creating new patterns
jc: difficult to support scrolling without an API that exposes fingerprinting
scrolling in multiple directions might be simpler to solve
think smaller WICG venue more suited to explore
<jcraig> ask me
<Zakim> jcraig, you wanted to show this is missing piece of posinset: Example: https://cookiecrook.com/test/aria/posinset/posinset.html
<https: //cookiecrook.com/test/aria/posinset/posinset.html>
in this example, ARIA features break down
so this proposal is useful
jg: maybe this is a marker, author has to decide what´s next piece of content
jc: the issue of element navigation complicates it
jg: just say ¨here´s where the new piece is¨, AT navigates to it
jc: that wasn´t part of it, browser can handle
most elements already rendered, just a few added
jg: <gets quiet and scribe has a hard time following>
jc: <also gets quiet and hyper-technical>
<sirens/>
jg: worried about throwing DOM away, need way to tell AT where to go
mck: can imagine a whole bunch of edge cases
I lean towards JC suggestion to take to incubator and circle back on ARIA feature
I do want to solve this problem
<jcraig> Specifically a WICG incubator group
ra: in summary, I hear people see the problem is valid
want to work on it, with some lean towards doing in WICG
I´m not opposed to that
<jcraig> Alice Boxhall will be interested in working on this too
next steps: continue work on technical details
would really like AT developers to be engaged
<names names>
jc: my advice from bitter experience is keep this effort contained at the start
<more summary scribe misses>
jg: <more quiet talk>
jn: let´s avoid making the perfect the enemy of the good
see room for big improvement with a good-but-not-perfect solution
jd: agree there´s a need for this
I´d like to separate out structural navigation aspect from the ¨next page¨ scrolling scenario
and address the structural bit elsewhere such as AOM
<Zakim> joanie, you wanted to ask about separating out the structural navigation
jc: potentially
though in this one, they know author has implemented scrolling
jc: trying to make AOM fingerprint free, this scenario pushes that
mr: yes, should explore but be aware of requests from AT
gg: there are heuristics already
mr: sometimes
jn: but if request sent, it´s clear
<jcraig> m/pushes that/follows that same pattern to use default scrolling/
mck: screen readers have trouble with scrolling views
don´t know when at the edge
do you want to go to first thing outside it
or stay inside it
facebook example, tabs after feed
usually you´ll scroll in feed, have to use a jump command to get out
sometimes user wants to replay content not trigger an unintentional scroll
does this address those cases?
jc: some, others out of scope
gg: this is improvement with explicit scroll request
currently some sites scroll whether you like it or not
jc: you mean by changing scroll position to beyond end?
mck: you´re trying to show where cursor is, which triggers scroll events
gg: yes
mck: wonky
gg: yes
mck: you´re doing something to trigger
gg: we added one piece of functionality, others observed and keyed off it
in ways we didn´t expect
jc: example?
gg: <scribe couldn´t capture>
<Zakim> jcraig, you wanted to mention how WebKit could reconcile nodes, even across innerHTML blits and to add this probably not work with custom (e.g. transform-based) scroll views
<mck> ack
jc: expect this not to work with custom transform-based scroll, just native scroll?
mr: yes
jc: yes, though might compromise its usefulness
<something detailed>
jd: don´t want to encourage infinite scrolling, though can´t prevent
so a reason incubating these difficult issues makes sense
jc, jd: <noodling>
<melanierichards> scribe: melanierichards
mck: I want to circle back to potentially blocking implementation detail. We had the quick brown fox jumped over the lazy dog, and we're talking about space separation between brown and fox, let's say somehow the author is able to say with ARIA that a space needs to be added between brown and fox. This space is added in the accessibility tree in the representation of the text node for brown
... it's appending a space to a text node
scribe note, brown is inside a div, fox is outside
mck: it sounded like there would be implementation problems w/ asking browser to do that
joanie: there's no space there, the text support would have to lie about what's there. Characters offsets have moved by one. What do you do with caret placement
mck: the goal we're trying to get to is, we want the screenreader to say "brown fox" instead of "brownfox", is there a way to do that without a space? Visually, using CSS, there's space between them
<HarrisSchneiderman> https://codepen.io/schne324/pen/ROmEJe
bgaraventa1979: if you specify that block-level elements do include whitespace around them, and inline-level elements don't, then everything falls into place.
mck: only for acc name calculation
... for these text nodes, we're not generating an accessible name for them
jcraig: I think what Bryan is saying is that if there are two elements displayed inline and not block item between them, you get them as a single string and that would work. I think what Matt is saying is that regardless of there's a space or not, block or not, would want to specify that they should be a single line concatenated with a space
... flip side, styling individual inline elements might ending up getting treated more like a block (separate characters rather than word) [paraphrased]
joanie: can't navigate by CSS generated content
bgaraventa1979: I can, in Firefox. [described doing so with JAWS]
joanie: CSS generated content IS exposed. But if you're not using an AT, CSS generated content cannot be selected with a mouse or searched. For SRs, it's a no-brainer to speak or render it, because it's exposed. For this new stuff, it's not in DOM, it's not in render tree, but screen readers should pretend it's there/
jcraig: [describing board] a new example with a div, which has 5 spans in it. Each has a single letter, Q, U, I, C, K, want to pronounce as a single word
[discussion about leading and trailing spaces]
mck: we were thinking of a space-separated token list for handling leading and trailing space on an element
Glen: this almost seems like it should be an attribute on the element following it
jcraig: but you can't do that on a text node, just an element node
Glen: ah so I guess we're back to square one
melanierichards: unless you specify that this has to be on an element node
joanie: it's not NOT, implementable, but I think it's going to be buggy as hell. There's going to be a lot of places where calculation isn't quite right
... I see bugs all the time with things like generated content, list item markers, etc. I have a lot of workarounds in Orca to just get ALL the text. I think we're going to see more broken text.
joanie; it can be dealt with, it's going to be flaky. The other thing I could see is selecting text via accessibility API. Now we're being lied to. I don't know that the space isn't really there
jongund: what happens with generated content?
joanie: can't select it, wouldn't be able to select it
mck: some people want to eliminate virtual buffers and go for caret navigation entirely, used to think that, but it's hard to make content understandable if you limit to the actual content. There's non-text content on the screen that has a lot of meaning. If you can't get there with a caret...
joanie: Orca will continually look to see if it can set a caret somewhere.
... this is going to be tricky to implement correctly, I think we're going to find a lot of edge cases and bugs, and we can keep working at it, but I don't think you should expect it to work correctly for awhile
jongund: [missed the question]
mck: the more we can encourage authors to override things, aria-hidden content etc, the better
jcraig: here's a couple real-world things I've experienced. Every letter in the word "quick" is in its own span, and I want to render it across an arc. They're probably not going to come across where the AT would treat these as a single word. That seems like a problem we should be able to solve.
... may lead to problems, but people are doing this today
... other ex. I've got a span with class "usd", and 9.99 inside it. CSS adds $ via generated content. If you were to position the generated content in such a way that it wouldn't be treated as a single text node with 9.99, you might run into the same problem and potentially have to add another span around the whole thing
mck: if there isn't an actual text node there, then text separation doesn't solve this problem
... generated content is an un-related content, we are tackling this issue because we decided div and span have the same generic role. There's block and inline stuff out there, right now we are relying on the browser to give the right separate based on visual styling in places
... ...for div and span
... generated content is a side issue, I don't think we should try to solve that while they're here now
jcraig: I mention that because the implementation details that are causing that will cause issues here
... maybe this problem is solvable in a different way. Instead of thinking about it as text separation, maybe it's white space collapsing
... inline, block, inline-block in CSS styling
... part of the reason this is getting complicated is because we're putting it on every child element and not on the parent and inherited, but then putting on the parent node is a bag of worms too. Though I don't think people would expect not being able to use it on the parent
... maybe put it on the parent and override on a child node if needed
mck: the other option is we don't tackle the problem at all. We go forward with generic and say in ARIA, if you use the generic role, the way you treat text nodes is completely handled by the browser....but you need to give the author some kind of control
<Zakim> joanie, you wanted to ask if we could get these examples fully marked up so we can see what the current state is in accessibility APIs and what's broken and what accessibility
joanie: I'm looking at these as a non-author...I don't know how to make the "quick" look like that (on an arc). While these may be all over the place, I want to see some basic, renderable examples and see how the different browsers render them. Maybe I can look at them and find out I can solve them right now as a SR dev
jamesn: can we mark them up and put them in the issue?
... some of the issues I've seen is an underline within a button name indicating the access key, and that would break up the text, but I haven't seen that in awhile
joanie: let the SRs and UAs look at these and think of what the possible author solutions might be
mck: it'll be easy for me to find examples where spaces are missing, the example where there SHOULDN'T be spaces I've seen but seems rarer
jcraig: Melanie might have an example of the latter
<bgaraventa1979> relevent examples are included within the AccName Prototype archive on github, in the folder "Proposed Name and Description Tests"
<bgaraventa1979> specifically the test cases named "Name file-label-inline-block-elements.html" and "Name file-label-inline-block-styles.html"
jcraig: both div and span are generic elements which have been associated with some styling basics which may be expressed through the API. Maybe the difference here should be exposed through APIs. Doesn't necessarily have to be through a role
mck: the original property we thought of was inline, block
joanie: originally we said two different roles but then James said they are exposed the same on his platform anyway
jcraig: coming around to some concept of inline and block
mck: with text-separation we thought, maybe we can solve another problem here
bgaraventa1979: if you get the chance I would recommend reading the files
... going to post it on Github, the AccName prototype I'm working on
... what I discovered is it's not just the difference between divs and spans that are important. Block and inline, depending on how they are arranged can completely screw up the ability to read anything properly
<bgaraventa1979> repo https://github.com/WhatSock/w3c-alternative-text-computation
mck: maybe we should just tell people to put a space in between things another way if they need it
jcraig: even if they do add that space, if they're block level, the inter-text spaces may not be rendered in the text range
... joanie, is that what you were saying?
joanie: spans that don't have any reason to be placed in the a11y tree, their text just gets sucked up into the parent element. In FF, any spaces in that case would be preserved
[people are not sure what would happen on MacOS]
[people exclaim that we need test cases]
bgaraventa1979: the way I coded the examples, it's adding spaces depending on whether there's block or inline elements, and the name is rendered correctly
jcraig:
joanie: I still think the next step is to make some simple test cases and find out what UAs and SRs are doing
jamesn: question is, can people using web components do the right thing and not worry about implementations
HarrisSchneiderman: I put some Codepens together
<HarrisSchneiderman> https://codepen.io/schne324/pen/NmVeEW
<HarrisSchneiderman> https://codepen.io/schne324/pen/eoabwW
<joanie> https://github.com/w3c/aria/issues/699
bgaraventa1979: I'd recommend doing it automatically and maybe you don't get all the cases but you'll get most of them
mck: want to give authors a way to provide the good experience in a deterministic way
jcraig: we could do it on an individual node but that would only effect how that node is rendered. If you did it on a parent, that would effect the space between the child nodes
jamesn: if you did it on 2 individual nodes, would that impact the spacing between them?
... for this kind of thing, not concerned about if it's difficult for author to implement, but whether it's difficult for an author to understand
jongund: how do browsers map these today, div and span?
joanie: we were looking at the HTML-AAM table for that earlier today, but it's wrong
jcraig: [paraphrasing, "it depends"]
mck: today's situation is that it seems browsers guess in different ways on how to put nodes in the tree based on styling
jcraig: I would say more an artifact of using the render tree
<HarrisSchneiderman> https://s.codepen.io/schne324/debug/NmVeEW/jVMpoyQVKZRk
bgaraventa1979: the same thing occurs with children presentational. Browsers will flatten them out differently, inline vs block spacing
jcraig: probably, yes
jamesn: we need examples of these so we can work out what's a bug etc
mck: there's no bug if there's no spec that says what should happen
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 0.98) Succeeded: s/I question the place to remove spaces/I question the need to add spaces/ Succeeded: s/someone wrote a spider/Simon Pieters wrote this query/ Succeeded: s/test// Succeeded: s/proposa/proposal/ Succeeded: s/attributes/role attribute/ Succeeded: s/aq?// Succeeded: s/single string/single text node/ Found embedded ScribeOptions: -final *** RESTARTING DUE TO EMBEDDED OPTIONS *** Present: James_Nurthen Jon_Gunderson Harris_Schneiderman Kurt_Bellew Melanie_Richards Bryan_Garaventa Michael_Cooper Glen_Gorden Joanmarie_Diggs Matt_King James_Craig Carolyn_MacLeod Rossen_Atanassov Found Scribe: jongund Inferring ScribeNick: jongund Found Scribe: jongund Inferring ScribeNick: jongund Found Scribe: HarrisSchneiderman Inferring ScribeNick: HarrisSchneiderman Found Scribe: glen Found Scribe: Glen Inferring ScribeNick: Glen Found Scribe: MichaelC_travel Inferring ScribeNick: MichaelC_travel Found Scribe: melanierichards Inferring ScribeNick: melanierichards Scribes: jongund, HarrisSchneiderman, glen, MichaelC_travel, melanierichards ScribeNicks: jongund, HarrisSchneiderman, Glen, MichaelC_travel, melanierichards 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: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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]