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



From: "John Foliot" <john.foliot@deque.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "'Joseph Scheuhammer'" <clown@alum.mit.edu>, "'Cynthia Shelly'"
            <cyns@microsoft.com>, "'David Bolter'" <dbolter@mozilla.com>,
            "'Dominic Mazzoni'" <dmazzoni@google.com>, "'James Craig'"
            <jcraig@apple.com>, "'WAI Protocols & Formats'"
            <public-pfwg@w3.org>, "'Alexander Surkov'"
            <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>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "'Joseph Scheuhammer'" <clown@alum.mit.edu>, "'Cynthia Shelly'" <
cyns@microsoft.com>, "'David Bolter'" <dbolter@mozilla.com>, "'Dominic
Mazzoni'" <dmazzoni@google.com>, "'James Craig'" <jcraig@apple.com>, "'WAI
Protocols & Formats'" <public-pfwg@w3.org>, "'Alexander Surkov'" <
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>
To: "'James Craig'" <jcraig@apple.com>, "'Joseph Scheuhammer'" <
clown@alum.mit.edu>
Cc: "'WAI Protocols & Formats'" <public-pfwg@w3.org>, "'Dominic Mazzoni'" <
dmazzoni@google.com>, "'Alexander Surkov'" <surkov.alexander@gmail.com>,
"'David Bolter'" <dbolter@mozilla.com>, "'Cynthia Shelly'" <
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>
> 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 -
> >
>