RE: [html-techs] Feb 13 2012 meeting cancelled.

Aria landmark has been completed in response to the comments.

 

Sorry I had sent them to the WCAG editors last week...

http://www.w3.org/WAI/GL/wiki/Using_ARIA_landmarks

 

comments found here:

https://www.w3.org/2002/09/wbs/35422/20120126misc/results

 

 


Detlev Fischer

Accept this with the following changes

Two issues: 

(1) Is this technique earmarked as sufficient technique for 2.4.1? There are
no user agent and assistive technology support notes that would detail the
level of support across the istalled base. Should the current recommendation
be to use landmarks as additional technique to meet SC 2.4.1, but not as
sole means? That might make it an advisory technique at the time being.

(2) I remember some tests have shown problems with redundant use of ARIA
landmarks and structural elements in HTML5 (some screen readers announcing
role twice in particular UA/AT combos). Should this be covered? Not sure
what the best practice would be right now.

 

Added support notes

Reject comment #2... not worried about redundancy for such a short phrase
and only 5 or 6 elements on a page... More important to have structure

 


Christophe Strobbe

Accept this with the following changes

Regarding applicability: Perhaps we should scope the applicability of the
technique to technologies where these landmarks have accessibility support.
(As far as I know, you can also use WAI-ARIA in SVG Tiny 1.2
<http://www.w3.org/TR/SVGTiny12/struct.html#RoleAttribute> but I doubt that
there is any accessibility support.)

Regarding the HTML5 examples: Section 7.5 of the WAI-ARIA spec says:
"WAI-ARIA roles, states, and properties are intended to add semantic
information when native host language elements with these semantics are not
available, and are generally used on elements that have no native semantics
of their own."
<http://www.w3.org/TR/wai-aria/complete.html#host_general_conflict> If
duplicating native HTML5 semantics with WAI-ARIA roles leads to duplicate
announcements in AT, wouldn't it be better to take out e.g. the nav example
and add a warning about duplicating semantics?

Test procedure: The above would also affect the test procedure. We could add
for example: 3. Check that the landmark attribute does not duplicate the
element's native semantics. (If duplicate announcements in AT are considered
an AT bug, this point may be moot, but I think that duplication of role
information just leads to maintenance overhead. As software developers say:
DRY: "Don't repeat yourself".)

 

Changed applicability...Limited it to HTML support...

 

-Regarding the HTML5 question... I think that should be extended to a wider
question. Do we want to separate out HTML5... Currently the semantics of
HTML5 are not exposed to most accessibility API's and so these Landmarks are
necessary. The only redundant one in those examples currently would be
Firefox 10.

 

Also, not too worried about a redundancy of one word from an accommodation
perspective. 

 


David Todd

Accept this with the following changes

Should an author be required to uniquely label multiple landmarks of the
same type?

Regarding the HTML5 examples, don't the semantics of the elements themselves
communicate the necessary accessibility information?

 

I don't think unique labels are an issue with landmarks, except <DIV>s of
course have to have unique ids... which is already covered.

Regarding HTML5, see above responses

 


Frederick Boland

Accept this with the following changes

need to document degree of widespread support for implementing this
technique as well as any known issues

 

Mostly done... feel free to add anything else known...

 


Michael Cooper

Accept this with the following changes

Pretty good start. The description seems to assume you know about the role
attribute. 


Michael Cooper

Accept this with the following changes

Pretty good start. The description seems to assume you know about the role
attribute. I suggest a paragraph saying that landmarks are put in with the
role attribute on the element, whose value is the name of the landmark. Also
in the list the landmark names start with a cap, but the role value has to
be all lower case, so they should be shown that way in the list.

Also in the list the landmark names start with a cap, but the role value has
to be all lower case, so they should be shown that way in the list.

 

Done!

 


Marc Johlic

Accept this with the following changes

Agree with comments from Christophe, David, and Michael. 

Also, consider adding a statement around using the "region" landmark to
avoid orphaned content that doesn't fit properly into the others listed.

Check Resources link - should be: http://www.w3.org/TR/wai-aria-practices/

 

Done!

 


Loretta Guarino Reid

Accept this with the following changes

This is an interesting draft, and may make a good proposal for the Task
Force to start with. I think the test procedure is a little vague, and we
will need to decide how much of the spec gets repeated, or how we reference
parts of the spec. I would also like to see the description focus less on
selling how easy this is and more on telling someone who is not familiar
with ARIA what this technique is, that is, how to use the markup.

 

I agree that we have to make a decision re: HTML5. A compelling reason to
leave HTML5 in this technique is the issue that HTML5 sections are not
supported well, but ARIA is, which is in fact it's purpose, to bridge
unsupported features of technology. I took out the sales line about how easy
it is. Tried to simplify and be more specific in the test. Tried to be
further explain what a Landmark is to a lay person. 

 

Cheers

David MacDonald

 

... access empowers ...

                 ... barriers disable ...

www.eramp.com

 

 

Cheers

David MacDonald

 

... access empowers ...

                 ... barriers disable ...

www.eramp.com

 

 

-----Original Message-----
From: James Nurthen [mailto:james.nurthen@oracle.com] 
Sent: February-11-12 11:15 PM
To: W3C WAI Protocols & Formats
Cc: WCAG; wai-xtech@w3.org; Cynthia Shelly
Subject: [html-techs] Feb 13 2012 meeting cancelled. 

 

The meeting scheduled for Feb 13 has been cancelled. 

 

As we don't have any techniques to review it would be better to spend the
meeting time working on writing technique(s) so we have something to review
next week. Sorry for the late notice but I was hoping we would have
something to review this week.

 

Regards,

James