w3c / wcag Goto Github PK
View Code? Open in Web Editor NEWWeb Content Accessibility Guidelines
Home Page: https://w3c.github.io/wcag/guidelines/22/
License: Other
Web Content Accessibility Guidelines
Home Page: https://w3c.github.io/wcag/guidelines/22/
License: Other
Name: Chaals McCathie Nevile
Email: [email protected]
Affiliation: Yandex
Document: W2
Item Number: Guideline 1.4: Make it easier for users to see and hear content...
Part of Item:
Comment Type: technical
Summary of Issue: graphics contrast is unmentioned (except as exceptions)
Comment (Including rationale for any proposed change):
None of the contrast requirements in guideline 1.4 apply to graphics, except where specific types of graphics are specifically exempted.
This fails to account for primarily graphic applications, such as maps, traffic indication, wayfinding tools, and many others.
People have a primarily visual interaction with the Web. Where graphics are presented as a key part of an interface, even given a text-based alternative, many people will rely on the graphics.
It is therefore important to require sufficient accessibility of graphics content for visual users.
Proposed Change:
Add requirements for appropriate visual contrast in graphics used to provide functionality of a site or application.
In the file:
https://github.com/w3c/wcag/blob/master/wcag20/sources/failure-tech-src.xml
i.e., see:
This is very confusing. The reader does not know what to follow: procedure or title.??
https://lists.w3.org/Archives/Public/public-comments-wcag20/2015Jun/0002.html
Name: Nick Levinson
Email: [email protected]
Affiliation: none
Document: W2
Item Number: Guideline 2.2: Provide users with disabilities enough time to read...
Part of Item:
Comment Type: technical
Summary of Issue: if auto-redirect despite WCAG but UA blocks, tell user where to go
Comment (Including rationale for any proposed change):
Pages that refresh so that information is lost may violate WCAG 2.0 guideline 2.2, but refreshing is common anyway. However, a browser may prevent refreshing unless the user chooses to refresh. That's a good solution, but with one caveat: the user may not know why refreshing is supposed to occur, and the user should be well-informed so they can decide what to do next, which may be to do what the redirection was supposed to do. Therefore, the page before refreshing should say why it should refresh.
Example: I recently designed a website with a complicated directory structure. Many directories contained only subdirectories. A visitor to one would get a message from my host saying basically that there's nothing to see here. So, I prepared nonroot index.html files that would auto-redirect the visitor to a page. (I since changed my mind, and they no longer auto-refresh.) In the time before auto-redirection, the page would say what would happen, and would provide links, one to do the same thing as auto-redirection and the other to provide an alternative destination (the home page). So, if the browser prevented redirection, the user would know what to do anyway.
Proposed Change:
If auto-redirection is used despite violating WCAG, since a browser may block auto-redirection, tell the user what the intent was and provide a means of doing it manually. This advice can go into a document that supports WCAG today or a future revision of WCAG.
ARIA2: Identifying a required field with the aria-required property. http://www.w3.org/TR/WCAG20-TECHS/ARIA2.html
Code error 1: The 3rd example shows individual radio button with the aria-required property. I believe this is incorrect. According to the ARIA spec ( http://www.w3.org/WAI/PF/aria/states_and_properties#aria-required), "aria-required" is not supported on role="radio" (it should be on the element with role="radiogroup").
Code error 2: Also noticed that the id is left off of the element.
Existing and corrected code samples provided:
Existing code sample for Example 3:
Account NumberPlease send an alert when balance exceeds $3,000.
Here is how I think Example 3 should be constructed ("id" added to the input element; moved "aria-required" to radiogroup):
Account NumberPlease send an alert when balance exceeds $3,000.
end
Probably a mistake but ARIA1 (ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls) is not a sufficient technology to associate a page title for SC 2.4.2 'Page titled'.
http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html
It should get removed as a sufficient technique on SC 2.4.2
[Fatal Error] H2.xml:26:6: The element type "p" must be terminated by the matching end-tag "
".https://github.com/w3c/wcag/blob/Working-Branch-for-Fall-2014/wcag20/sources/techniques/html/H2.xml
Description, second paragraph:
For simple data tables where the header is not in the first row or column, like the one in Example 1, this technique can be used. Based on screen reader support today, its use is suggested in two situations both relating to simple tables: :
At the end of the paragraph is a colon that is not needed.
From: Glenda Sims/DEQUE
Summary of Issue: Conflict between glossary definition of label and H65 sufficient technique for 3.3.2
Comment (Including rationale for any proposed change):
The Normative definition for label clearly says "Note 1: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same." But there is a sufficient technique (H65) for 3.3.1 that allows title (or hidden labels) to be used. BUT..this is in direct conflict with the definition of label.
Proposed Change:
Remove H65 as a sufficient technique because it does not allow you to pass 3.3.1 (because it does not provide the label information for all users (only provides it for screen reader users).
I was looking at normalizing the formatting through out the repo.
To do this I suggest adding an http://editorconfig.org file so that going forward IDEs will self normalize.
Few questions to answer for the config file:
In the file:
https://github.com/w3c/wcag/blob/master/wcag20/sources/failure-tech-src.xml
The technique F47 should make a reference to the own documentation of Mozilla, where the use of blink is deprecated and discouraged:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/blink
There are a few options for building out the gh-pages
branch, but here are a few decisions to make:
gh-pages
branch or keep it as a single commit orphan branchThis is a commenting test.
A problem with this URI http://test.test.ie
Some code:
Wow, that heading is amazing.
Some test heading
Wow, that heading is amazing.
Some test heading
Wow, that heading is amazing, but can I see the code?
We need specific examples which can be applied to "Third Party Content".
Examples of issues including, but not limited to:
Examples of issues including, but not limited to:
In many cases, they are not content that are under the author's control. Authors don't have any alternatives as the codes are officially provided from the third party they are using. For example, when they are using Twitter, there is no option. Authors have no choice but to use the plugin which is officially provided by Twitter even if they already found an issue to be fixed.
However, WCAG says "it is not possible to know at the time of original posting what the uncontrolled content of the pages will be." Authors can check if the third party content is WCAG conformant before they use it.
Can we apply "Statement of Partial Conformance - Third Party Content" to them?
We should have specific examples in "Understanding WCAG 2.0" to clarify what would be included and what would not be included.
The area of low vision a11y and WCAG is a topic that needs attention.
Some specific areas are:
1)The priority levels of SCs relating to low vision users and the public perception that they are somehow less important.
2) Can we have better more current techniques for developers when building sites/apps for Screen Magnification users? advances in ARIA, being able to move focus etc need to be accommodated in our techniques.
3) Should we revisit our colour contrast algorithm? Should it enforce higher levels of contrast between foreground and background colours? Can we identify instances where ratios need to be higher - headings/ error messages/?
4) Scrolling and screen magnifiers - we need to understand any current problems.
5) Could we have a tutorial for developers to address low vision user needs and also screen magnification users.
6) What supports can UAAG provide on the platform/UA side for Low vision?
[and more from the https://www.w3.org/WAI/GL/wiki/Post_WCAG_2]
Raise SC 1.4.3: Contrast (Minimum) to Level A
Contrast of Hover and Link Text States
Contrast in Icons
http://lists.w3.org/Archives/Public/public-comments-wcag20/2015Jan/0009.html
We are reviewing and modifying our Japanese translation of WCAG 2 for JIS refresh.
We have a request on "general flash and red flash thresholds" in "Appendix A: Glossary".
It reads "Note 2: A transition is the change in relative luminance (or relative luminance/color for red flashing) between adjacent peaks and valleys in a plot of relative luminance (or relative luminance/color for red flashing) measurement against time."
Could you restate Note 2 in different words (in plain English)?
My name is Miko Zabusek. I Slovak journalist translator.
Your web page is very interesting for my readers and friends. Therefore, I
ask Your written permission to translate Your page, which is located at the
http://www.w3.org/TR/WCAG20/
http://www.hixie.ch/specs/pingback/pingback-1.0
http://www.complete-review.com/main/editorial.htmlThat’s why I'm asking
your link back to my future translation.
Thank you anyway!
http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-refs
There are several instances of [begin add] [end add] and [begin delete] [end delete] that need to be cleaned up throughout the "How to Meet WCAG 2.0" quick reference document.
See Sufficient Techniques for 1.1.1 - all of the ARIA techiques as an example.
[begin delete] [end delete]
We need specific examples which can be applied to "Third Party Content".
Examples of issues including, but not limited to:
Examples of issues including, but not limited to:
These plugins, players and widgets can be updated without notice. The update is also not under author's control.
For example, an author embedded a third party's widget which was conforming to WCAG in a website and the website made a conformance claim at that time. After that, the widget was updated by the third party and the updated version has an issue which fails a success criterion.
If the widget is considered to be a "Third Party Content", "Statement of Partial Conformance - Third Party Content" could be made. If not, the website won't be able to make a partial conformance claim as well as a conformance claim due to the failure.
In many cases, they are not content that are under the author's control. Authors don't have any alternatives as the codes are officially provided from the third party they are using. For example, when they are using Twitter, there is no option. Authors have no choice but to use the plugin which is officially provided by Twitter even if they already found an issue to be fixed.
As a precondition of "Statement of Partial Conformance - Third Party Content", WCAG says "it is not possible to know at the time of original posting what the uncontrolled content of the pages will be." Actually authors can check if the third party content is WCAG conformant before they use it. But "it is not possible to know at the time of original posting what the uncontrolled content (= upcoming version of the third party content) of the pages will be".
Can we apply "Statement of Partial Conformance - Third Party Content" to these plugins, players and widgets?
We should have specific examples in "Understanding WCAG 2.0" to clarify what would be included and what would not be included.
The followings are just images. It doesn't mean that they fail under WCAG SC.
Submitter's Name: aurelien levy
Submitter's Email: [email protected]
This failure occurs when people with low vision are not able to read text that is displayed over a background color. When there is not sufficient contrast between the background color and the text color, features of the background color can be confused with the text color making it difficult to accurately read the text.
To satisfy Success Criterion 1.4.3 and 1.4.6, there must be sufficient contrast between the text color and its background color.
Example 1 Head: Failure Example 1
Example 1 Description:
Black text overlays a dark grey background
h2{
color:#000000;
background: #515151;
}
Example 2 Head: Failure Example 2
Example 2 Description:
Black text overlays a background with a css vertical gradient from black to white.
h2{
color:#000000;
background: linear-gradient(to bottom, #FFFFFF 0%,#000000 100%);
}
Test Procedure:
1.Quickcheck: First do a quick check to see if the contrast between the text and the area of the background color that is darkest (for dark text) or lightest (for light text) meets or exceeds that required by the Success Criterion (1.4.3 or 1.4.6). If the contrast meets or exceeds the specified contrast, then there is no failure.
2.If the Quickcheck is false, then check to see if the background color behind each letter has sufficient contrast with the letter.
Expected Result:
If Quickcheck is false and #2 is false as well then this failure condition applies and the content fails the contrast Success Criterion.
Additional Notes:
this failure relates to 1.4.3 and 1.4.6
I don't understand why there is still no failure against text contrast ratio and I think we also need to ask for at least a 3.0:1 ratio for icons used without text.
It's a more and more common issue especially with responsive website and social sharing.
There is already a technique for that "Making icons using simple line drawings that meet the contrast provisions for text (future link) " but in advisory techniques for now.
So I think we need two new failures like :
Failure of Success Criterion 1.4.3 and 1.4.6 due to using icons that do not provide sufficient contrast with background
Failure of Success Criterion 1.4.3 and 1.4.6 due to using text that do not provide sufficient contrast with background
Name: Moe Kraft
Email: [email protected]
Affiliation: IBM
Document: UW
Item Number: Understanding Success Criterion 1.4.3
Part of Item: Sufficient Techniques
Comment Type: technical
Summary of Issue: Can text shadowing be used to meet minimum contrast requirements?
Comment (Including rationale for any proposed change):
On a recent design review call, the designer proposed that although the text color does not meet sufficient contrast minimum requirements with the background color or image, the border around the text does meet contrast minimum requirements and that the text with shadowing should be sufficient to meet the success criteria of 1.4.3.
Is this possible? Should there be guidelines on the weight/thickness of the shadow and that it goes around all the text and not just one side?
Should this be entered as a proposed technique?
A good sample can be seen in the article, Design Accessibly, See Differently: Color Contrast Tips And Toolshttp://www.smashingmagazine.com/2014/10/22/color-contrast-tips-and-tools-for-accessibility/ In the Pay Now images, the middle column shows text with a drop shadow on the foreground text and the tests are in Normal view, gray scale and deuteranopia. http://media.mediatemple.netdna-cdn.com/wp-content/uploads/2014/10/buttongradients-large.png
Name: Mark Rogers
Affiliation: PowerMapper Software
Document: TD
Item Number: F68
Part of Item: Applicability
Comment Type: technical
Comment (Including rationale for any proposed change):
The procedure says "For all input elements except those of type "radio", "submit", or "reset", and all textarea and select elements in the Web page:"
The procedure requires programatically associated labels for input type=hidden. It also allows input type=radio without programatically associated labels.
Proposed Change:
Change "radio" to "hidden" in "For all input elements except those of type "radio", "submit", or "reset", and all textarea and select elements in the Web page:"
http://www.w3.org/TR/WCAG20-TECHS/F91.html#F91-tests
It says (replaced # with § to avoid GitHub issue confusion)
Expected Results
- If all checks §1 - §4 are false, then this failure condition applies and the content fails the Success Criterion.
As there are six checks, I think the correct sentence would be
- If all checks §1 - §6 are false, then this failure condition applies and the content fails the Success Criterion.
http://www.w3.org/TR/WCAG-TECHS/F17.html and https://github.com/w3c/wcag/blob/master/wcag20/sources/failure-tech-src.xml
The expected result is formulated wrongly:
"If step #1, step #3 or step #4 is true or step #2 is false, then this failure condition applies and the content fails the success criterion."
"If step #1 is true or step #2 is false or step #3 is false or step #4 is false, then this failure condition applies and the content fails the success criterion."
We have a technique for Creating PDF headers and footers, usually inserted
using the source program such as MS Word Headers and Footers. See PDF14.
http://www.w3.org/TR/WCAG20-TECHS/PDF14.html
This causes the screen reader to announce these Headers and footers at the
top and bottom of every page. Sometimes the interrupt reading halfway
through a sentence that continues on the following page. I can imagine this
is quite annoying for screen reader users tp have to listen through a header and a footer between every page.
Visually we just skip over it... Usually most of the information found in the header and footer is available on the home page of the document or some other prominent place.
What is useful is page numbers. However, if the author syncs the page
numbering of the PDF with the document large numbers using PDF17, it makes
me wonder if we should advise the author to mark headers and footers as
artifacts instead...
An organization that teaches PDF, which is fairly well known, and has done
work for Adobe teaches to turn these headers and footers into artifacts so
they will be ignored by a screen reader.
I propose we place a note on PDF14 saying something like this:
"If the page numbering has been synchronized as in PDF17 and other header
and footer information is available in a prominent place in the document
such as a heading or home page, then headers and footers are not necessary
and can be marked up as artifacts..."
Andrew responds on list
David,
I’m sure that we can debate the right thing to do with header and footer information and still not come to full agreement. But I agree that repeating “© 2015 MyCorp Industries” or even just the “page 1 of 8” sequence can get tedious for a blind user.
PDF/UA speaks to this:
7.8 Page Headers and footers
Running headers and footers shall be identified as Pagination artifacts and shall be classified as either Header or Footer subtypes as per ISO 32000-1:2008, 14.8.2.2.2, Table 330.
I agree that we need to do something with the PDF14 technique.
Katie responds on list
Great catch David!
Jonathan responds
David, there are some good but very specific reasons to not artifact header and footer information. Otherwise running headers and footer should be made pagination artifacts and the Page Labels feature should be used to add Page numbering including section information to identify pages and sections to assistive technology. The page label feature is pretty powerful and allows flexibility for different number schemes such as Roman numbers and custom label prefixes.
Some instances of header and footer information that might be useful include classification information on classified documents, copyright information, form numbers, or other content that is not located elsewhere in the document. In general I recommend marking that content as non-artifact content on the first and last page so it does not break up the reading order of content.
In the ARIA XML source I think there are wrong idrefs - instead linking to success criteria they are linking to Guidelines. This is only for text-equiv
e.g.
success-criterion idref="text-equiv" relationship="sufficient"
Dfferent markup for property in ARIA-techniques:
"aria-required property" (like in 411, 513 - prop) or
"aria-describedby property" (like in 2052 - att) and "aria-labelledby property" (like in 1330-1335 - att)?
The link “Accessible Rich Internet Applications (WAI-ARIA) 1.0, Supported States and Properties” links to Not All ARIA Widgets Deserve role="application" instead of http://www.w3.org/TR/wai-aria/states_and_properties
C31: Using percent for font sizes
Important Information about Techniques
See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how they relate to the normative WCAG 2.0 success criteria. The Applicability section explains the scope of the technique, and the presence of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2.0.
Applicability
CSS
This technique relates to:
• Success Criterion 1.4.4 (Resize text)
o How to Meet 1.4.4 (Resize text)
o Understanding Success Criterion 1.4.4 (Resize text)
• Success Criterion 1.4.5 (Images of Text)
o How to Meet 1.4.5 (Images of Text)
o Understanding Success Criterion 1.4.5 (Images of Text)
• Success Criterion 1.4.8 (Visual Presentation)
o How to Meet 1.4.8 (Visual Presentation)
o Understanding Success Criterion 1.4.8 (Visual Presentation)
• Success Criterion 1.4.9 (Images of Text (No Exception))
o How to Meet 1.4.9 (Images of Text (No Exception))
o Understanding Success Criterion 1.4.9 (Images of Text (No Exception))
User Agent and Assistive Technology Support Notes
See User Agent Support Notes for C12.
Description
The objective of this technique is to specify text font size proportionally so that user agents can scale content effectively. Percent, named or em units can be used. If the size of the font is specified for the body element, all other elements inherit that value, unless overridden by a more specific selector.
This technique (C31) is the combination of three previous CSS techniques that addressed relative font sizes separately (C12, C13 and C14).
Examples
Example 1: Percent font sizes in CSS
This example defines the font size for the strong element so that its text will always be larger than the surrounding text, in whatever context it is used. Assuming that headings and paragraphs use different font sizes, the emphasized words in this example will each be larger than their surrounding text.
Example Code:
strong {font-size: 120%}
...
Since only the user can know what size text works for him, it is very important to let him configure the text size. … Example 2: Named font sizes in CSS This example selects a larger font size for strong elements so that their text will always be larger than the surrounding text, in whatever context they are used. Assuming that headings and paragraphs use different font sizes, the emphasized words in this example will each be larger than their surrounding text. Example Code:
strong {font-size: larger}
...
Since only the user can know what size text works for him, it is very important to let him configure the text size. … Example 3: Em font sizes in CSS This example defines the font size for strong element so that its text will always be larger than the surrounding text, in whatever context it is used. Assuming that headings and paragraphs use different font sizes, the strong words in this example will each be larger than their surrounding text. Example Code:
strong {font-size: 1.6em}
...
Since only the user can know what size text works for him, it is very important to let him configure the text size.
…
Resources
Resources are for information purposes only, no endorsement implied.
• Cascading Style Sheets, Level 2 (CSS2), Fonts
• CSS 2 Font Size Property
Tests
Procedures
Name: Detlev Fischer
Affiliation: 3needs
Document: TD
Item Number: F3
Part of Item: Tests
Comment Type: technical
Comment (Including rationale for any proposed change):
The third step in the test of F3 says "If an image does convey important information, the information is provided to assistive technologies and is also available when the CSS image is not displayed".
Since assistive technologies are mentioned immediately before the bit "is also available", it is no unambiguously clear that the intent here is to require also the visible presence of replaced text when content is viewed with CSS disabled (i.e. in cases where background images disappear and some suitable alternative text that is off-screen-positioned when CSS is active is shown instead).
An additional suggestion: The use of CSS background images for controls is now very frequent, so I wonder whether a sufficient technique describing replaced text (off-screen positioned when CSS is active, replacing the image when CSS is off) would be a good idea. Such a technique currently does not exist, I bevieve. Should I draft something?
Proposed Change:
Change third step of F3 test to:
"If an image does convey important information, the information is provided to assistive technologies and is available both visually and programmatically when the CSS image is not displayed".
There is a small syntax error in both the examples: the content of the style attribute is not closed by an quotation mark.
http://www.w3.org/TR/WCAG20-TECHS/F69.html
https://www.w3.org/2006/02/lc-comments-tracker/35422/NOTE-WCAG20-TECHS-20140911/2992
I always wondered why in Techniques for WCAG 2.0 there are three different techniques (c12, c13 and c14) for the same problem, ie how to specify text font size.
My proposal is to merge them together in a single technique
Proposed Change:
A new technique that will merge c12,c13 and c14.
Its procedure will be:
Expected Results
Content injection via pseudo-elements ::before & ::after and the 'content' property:
Existing Techniques and Failures in this area:
Might just need some edits to these existing Techniques and Failures with language that is more specific to CSS generated content, nav-index, and 'order'.
Any other thoughts or suggestions on this topic?
We have three broken links in G87: Webaim Captioning Tutorials. I've tried the webaim-search but couldn't find them.
https://www.w3.org/2006/02/lc-comments-tracker/35422/NOTE-UNDERSTANDING-WCAG20-20140911/2995
Comment (Including rationale for any proposed change):
I think the choice of words selected to replace 'web page' ('document' and 'program') is not the best choice of words to use. I believe the word 'screen' is much more appropriate. As we are already using that word and it is used in every software development practice and not just websites/web apps. In addition, the choice to use 'software program' I believe is too large of a unit to measure.
Proposed Change:
use the word 'screen' and/or 'set of screens' for defining the unit of measure.
In the file:
https://github.com/w3c/wcag/blob/master/wcag20/sources/failure-tech-src.xml
i.e.:
http://www.w3.org/TR/WCAG-TECHS/F17.html
"For client-side image maps, check that the value of the usemap attribute has a corresponding id value if the usemap attribute is not a URI."
According to the HTML 4.0.1 specification the usemap attribute must be an URI and must match the value of the name attribute of another map element.
I'm seeing many people use this technique as a normative type document to meet the labels and instructions SC that requires visible labels. They are applying it to incorrect situations like many text inputs in a shipping address fieldset with placeholders and no visible labels. I could see how it applies in the 4 specific situations listed in H65 but beyond that it should not be valid.
This technique causes many developers and designers to say well WCAG allows a title on H65 so all we need is a title or some other visually hidden label. This is a major problem for mobile were everyone loves placeholders over labels. http://pauljadam.com/demos/wcagh65invalid.html
Thank you for any help in fixing the issue or correcting me on it if I'm crazy and visually hidden labels are really allowed on whatever text inputs you want.
https://www.w3.org/2006/02/lc-comments-tracker/35422/NOTE-WCAG20-TECHS-20140911/2994
The example suggests that the link text to the conforming alternate version be "Alternate version". This does not clearly identify that the link goes to an accessible version of the same content.
Proposed Change:
Replace: "Alternate version"
With: "WCAG-conforming alternate version"
Or: "WCAG-conforming alternate version of this page"
There seems to be a problem with technique F76. The failures XML document still contains it, but it has been deprecated in:
Is anyone hearing about issues with this from web content in production?
In the file:
https://github.com/w3c/wcag/blob/master/wcag20/sources/failure-tech-src.xml
i.e., see:
http://www.w3.org/TR/WCAG-TECHS/F24.html
Example #2 is using a "color" attribute on "body" element, which does not exist in the specification. Please, modify it.
https://www.w3.org/2006/02/lc-comments-tracker/35422/NOTE-WCAG20-TECHS-20140911/2997
I was doing some research on this technique and the UA notes:
http://www.w3.org/WAI/WCAG20/Techniques/ua-notes/html#H69
Opera hasn't supported keyboard heading navigation since switching from Presto to Blink in July 2013
http://forums.opera.com/discussion/1834402/navigation-over-links/p1
The Vimium extension they mention as a replacement doesn't appear to
support heading navigation either
The currently documented Opera keyboard shortcuts now look identical to other browsers:
http://help.opera.com/opera/Windows/1387/en/fasterBrowsing.html#keyboard
The Firefox landmark extension from TPG has been mentioned as an alternative, but this doesn't support heading navigation either. I've checked both the source code and and installed on a clean VM
https://github.com/matatk/landmarks
The other alternatives mentioned in the H69 UA notes either no longer work on current browsers or don't have working download links.
Conclusion: there's no longer UA support for this technique
Best Regards
Mark
Proposed Change:
Given there appears to be no current UA support for this technique for keyboard users, should it be retired?
If someone does find UA support for it, then the UA notes should be updated accordingly.
http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-refs
ARIA1 is listed as a Sufficient Technique for 2.4.4 Link Purpose in the "How to Meet WCAG 2.0" quick reference document.
However, ARIA1 is not listed in the Understanding document for 2.4.4:
http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-refs.html
Also, 2.4.4 Link Purpose is not listed in the Applicability section for ARIA1:
http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140916/ARIA1
Not sure if ARIA1 just needs to be removed from 2.4.4 in the How to Meet document, or if it needs to be added to the Understanding doc for 2.4.4 and have 2.4.4 added to Applicability for ARIA1
Why on the page https://github.com/w3c/wcag/network does a fork/clone still have the attribute of 'master' - surely there can only be one?
I have compared what PDF/UA and WCAG say about headers and footers and have written up a small report and recommendations on how I think we should proceed with Headers and Footers in PDF documents.
http://davidmacd.com/blog/pdf-headers-footers.html
I think we will need to update WCAG PDF14 to ensure it is clear that headers and footers will become artifacts and thtat the information needs to be available through other means (as in #1-3 below).I think PDF14 requires an update quickly. I could take an action item to propose the rewrite.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.