RE: aria-level a required property for role="heading" or a supported property with an RFC SHOULD for authors

I agree, the problem with something like ‘auto’ in a case like this, is that any ambiguity on the part of devs will always be met with ‘well just put auto on it’, and this will easily become a common practice across web apps. The assumption being that the browsers and ATs can figure it out, which is most often not the case due to the DOM nesting structure. E.G most heading structures are organized based on content meaning, not DOM hierarchy. No programming logic exists to parse the nesting structure of content meaning, and there never will be.

Since the cornerstone of accessibility is consistency, I think it would be good to indicate in the UAIG that not providing an explicit level for a heading would result in a default value being assigned, 2 sounds reasonable to me.

Also, if we can agree on this, adding aria-level as a required attribute for role=heading would help cement the importance of doing this in the minds of devs as well.

The first would cover instances where this is already being done and causing variable feedback across devices, and the second would help create more consistent UIs in the future.

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Sunday, June 21, 2015 10:57 AM
To: John Foliot
Cc: 'Joseph Scheuhammer'; 'Cynthia Shelly'; 'David Bolter'; 'Dominic Mazzoni'; 'James Craig'; 'WAI Protocols & Formats'; 'Alexander Surkov'
Subject: RE: aria-level a required property for role="heading" or a supported property with an RFC SHOULD for authors


John,

aria-level is also used in tree widgets. If we change aria-level like "auto" or "subsection" it will create other problems. Trees already work find with integer levels as trees are hierarchical.

The problem with headings is that they are not yet HTML has chosen to put a level on them without making them hierarchical in the DOM structure. There is probably good reasons for this as documents can span multiple pages.

I would be resistant to changing values in aria-level for these reasons. I don't want to try to "fix" things in other widgets that are not broken and have widespread adoption.

Rich


Rich Schwerdtfeger

[Inactive hide details for "John Foliot" ---06/19/2015 05:03:58 PM---Hi Rich,]"John Foliot" ---06/19/2015 05:03:58 PM---Hi Rich,

From: "John Foliot" <john.foliot@deque.com<mailto:john.foliot@deque.com>>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "'Joseph Scheuhammer'" <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>, "'Cynthia Shelly'" <cyns@microsoft.com<mailto:cyns@microsoft.com>>, "'David Bolter'" <dbolter@mozilla.com<mailto:dbolter@mozilla.com>>, "'Dominic Mazzoni'" <dmazzoni@google.com<mailto:dmazzoni@google.com>>, "'James Craig'" <jcraig@apple.com<mailto:jcraig@apple.com>>, "'WAI Protocols & Formats'" <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>, "'Alexander Surkov'" <surkov.alexander@gmail.com<mailto:surkov.alexander@gmail.com>>
Date: 06/19/2015 05:03 PM
Subject: RE: aria-level a required property for role="heading" or a supported property  with an RFC SHOULD for authors

________________________________



Hi Rich,

I’ll take the hit for re-stating some of the discussion in the minutes on list, as I’m not 100% sure those minutes captured the entire discussion. This has been an interesting and important thread, so much so that I’ve shared the gist of it internally at Deque, which has prompted some internal discussion and feedback from some of the non-sighted SMEs in our organization – to the point that despite what I originally thought was the right answer, I’ve actually changed my opinion and now believe that making declared aria-level values mandatory (RFC 2119 MUST) is the better of the choices we have, despite the very real probability of the data being wrong at least some of the time.  For example, I have received the following comment:

     “A heading without a level is like, well, it’s an HTML5 landmark.  It’s useful for navigation, but not very useful for understanding hierarchy.”

Respectfully Rich, saying “All IBM content must reside within a landmark.” is great when you have total control over the end-to-end “assembly” of the page of embedded ‘apps’ – but on the messy web, that cannot always be a mandated approach – that is author policy at your end. It also presumes that end users aren’t using Headings for navigation (maybe they are, maybe they aren’t) and/or that the *only* good way to navigate a web page with a screen reader is via landmarks (a slippery-slope proposition from my perspective – my dad has an expression about the word “assume”…)

Put another way, as Brian Garaventa wrote:

     “…the idea that we can have headings that have no level at all. That makes no sense and doesn't help any ATs in building out structured layouts for users. It actually breaks this by causing a gap in the ability to map an intuitive tree.”

Based upon that, I would suggest that while IBM’s current practice/policy is indeed a good Best Practices note, that practice alone does not negate the fact that headings require levels, a point that many of the non-sighted users on this thread are making.

Again, from internal emails:

     “So, today at [client], a real life example came up of: What to do with the heading level for dynamically inserted content when the heading level under which the content is being inserted is not known ahead of time?”

This is the issue/problem that James noted on the call, and it is a real issue/question/problem. The feedback we seem to be getting (albeit a small and non-controlled survey) suggests that an enumerated heading level (even if wrong) seems to be preferred over not being provided any enumeration (current practice with NVDA and Voice Over). From Leonie’s response:

     “…so far it seems that more people would prefer to have levels even if there is a risk they may not be accurate.”

At the risk of having things thrown at me (grin), I did want to ask if Jon Gunderson’s idea of adding two named values (aria-level=”auto” and aria-level=”subsection”) is worth exploring further. I’ve personally heard more positive feedback on that idea than I have negative, and while I am not a browser engineer, it seems pretty straight-forward to me.

I think providing that option would address a number of concerns: it answers James’ and [Deque employee]’s question about what to do when you don’t know the parent heading level, it allows for ensuring that aria-level is never “guessed” at (well, it is still something of a guess, but a guess based upon some author intent and heuristics), but most importantly it allows for clear author guidance in all scenarios.  Barring that, the idea that we request user agents to set a default level (Brian suggested level=”1”, but I’d be more comfortable with level=”2”, which is apparently what Jaws in FF and IE reports today when a level is undeclared) would be the better way forward. This BTW would still work nicely with the IBM requirements you previously mentioned.

Win-win.

JF


From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Friday, June 19, 2015 12:00 PM
To: John Foliot
Cc: 'Joseph Scheuhammer'; 'Cynthia Shelly'; 'David Bolter'; 'Dominic Mazzoni'; 'James Craig'; 'WAI Protocols & Formats'; 'Alexander Surkov'
Subject: RE: aria-level a required property for role="heading" or a supported property with an RFC SHOULD for authors


John, your response is restating what was already discussed in the minutes. We agreed to not do that. The demonstrable cases occurred because people were trying to keep a consistent heading level for an entire rich web application when applets from different parties were pulled in and you had to guess to re-write over it.  If you effectively used landmarks I don't see that being an issue.

All IBM content must reside within a landmark. We found that taking this approach dramatically increased the usability of all IBM RIAs. It allows you to effectively find all your content as nothing is orphaned and it restricts heading navigation to the context to which they were originally designed. Freedom Scientific tells end users to start your navigation with landmarks incidentally. Using this approach you pull up a table of contents (landmark navigation) and you are off to the races. You can skip content you don't care about.

We have found that making your page depend solely on heading navigation is a non-starter and makes the headings issue that James Nurthen talked about a very real problem which would mandate making it a SHOULD because frankly you just don't know what level to give it at times as you are trying to absorb an app, with heading navigation designed autonomously, in the middle of a page that was also built autonomously.

Rich

Rich Schwerdtfeger

[Inactive hide details for "John Foliot" ---06/18/2015 04:36:16 PM---Right, which again leads me to believe that this 'error' is]"John Foliot" ---06/18/2015 04:36:16 PM---Right, which again leads me to believe that this 'error' is not critical - it can be recovered from

From: "John Foliot" <john.foliot@deque.com<mailto:john.foliot@deque.com>>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "'Joseph Scheuhammer'" <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>, "'Cynthia Shelly'" <cyns@microsoft.com<mailto:cyns@microsoft.com>>, "'David Bolter'" <dbolter@mozilla.com<mailto:dbolter@mozilla.com>>, "'Dominic Mazzoni'" <dmazzoni@google.com<mailto:dmazzoni@google.com>>, "'James Craig'" <jcraig@apple.com<mailto:jcraig@apple.com>>, "'WAI Protocols & Formats'" <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>, "'Alexander Surkov'" <surkov.alexander@gmail.com<mailto:surkov.alexander@gmail.com>>
Date: 06/18/2015 04:36 PM
Subject: RE: aria-level a required property for role="heading" or a supported property  with an RFC SHOULD for authors

________________________________




Right, which again leads me to believe that this ‘error’ is not critical – it can be recovered from and still deliver usable and useful information to the end user.

This is why I am suggesting SHOULD language contextually: “Authors SHOULD provide a value for aria-level” (but not “Authors MUST provide a value for aria-level”) – we have demonstrable use-cases where that kind of stance might actually introduce as many issues as it may resolve.

JF

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Thursday, June 18, 2015 2:30 PM
To: John Foliot
Cc: 'Joseph Scheuhammer'; 'Cynthia Shelly'; 'David Bolter'; 'Dominic Mazzoni'; 'James Craig'; 'WAI Protocols & Formats'; 'Alexander Surkov'
Subject: RE: aria-level a required property for role="heading" or a supported property with an RFC SHOULD for authors


Yes, but lack of a level provides no level context and it does not align well with an HTML document whose native elements ALL provide a level. The question is not what the default behavior is when you leave it off but rather what we should be requiring authors to do. I think Mac does the best you can do in the absence of a level.


Rich Schwerdtfeger

[Inactive hide details for "John Foliot" ---06/18/2015 04:19:55 PM---+1, I have previously suggested that this is the better res]"John Foliot" ---06/18/2015 04:19:55 PM---+1, I have previously suggested that this is the better response (holy cow James, we're going 2 for

From: "John Foliot" <john.foliot@deque.com<mailto:john.foliot@deque.com>>
To: "'James Craig'" <jcraig@apple.com<mailto:jcraig@apple.com>>, "'Joseph Scheuhammer'" <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>
Cc: "'WAI Protocols & Formats'" <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>, "'Dominic Mazzoni'" <dmazzoni@google.com<mailto:dmazzoni@google.com>>, "'Alexander Surkov'" <surkov.alexander@gmail.com<mailto:surkov.alexander@gmail.com>>, "'David Bolter'" <dbolter@mozilla.com<mailto:dbolter@mozilla.com>>, "'Cynthia Shelly'" <cyns@microsoft.com<mailto:cyns@microsoft.com>>
Date: 06/18/2015 04:19 PM
Subject: RE: aria-level a required property for role="heading" or a supported property  with an RFC SHOULD for authors

________________________________





+1, I have previously suggested that this is the better response (holy cow
James, we're going 2 for 2 :-) ).

Leonie did some very quick real-time testing during our call, and (she will
correct me if I am wrong) she noted that in Firefox with NVDA (?) when the
level was not specified, it defaulted to "level 2" (which I think is a wrong
decision). Not sure where that decision is happening however, but suspect
it's in the screen reader.

JF


> -----Original Message-----
> From: James Craig [mailto:jcraig@apple.com]
> Sent: Thursday, June 18, 2015 2:14 PM
> To: Joseph Scheuhammer
> Cc: WAI Protocols & Formats; Dominic Mazzoni; Alexander Surkov; David
Bolter;
> Cynthia Shelly
> Subject: Re: aria-level a required property for role="heading" or a
supported
> property with an RFC SHOULD for authors
>
> VoiceOver used to speak "Heading Level 0, text content" but we fixed that
a few
> years ago. It now speaks "Heading, text content"
>
> James
>
> > On Jun 18, 2015, at 2:04 PM, Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>
> wrote:
> >
> > On 2015-06-18 3:06 PM, Bryan Garaventa wrote:
> >> Just to simplify my view, if heading levels are optional, ATs and
browsers will
> never provide consistent UIs, because they will always do something
different by
> guessing.
> >
> > Tangent:  What do Chrome, FF, IE, and Safari, do, in fact, when faced
with
> "heading", but no aria-level?  For example,
> >
> > <div role="heading>...</div>
> >
> > How is the level property mapped?
> >
> > --
> > ;;;;joseph.
> >
> > 'Array(16).join("wat" - 1) + " Batman!"'
> >           - G. Bernhardt -
> >
>