SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere Nutzervereinbarung und die Datenschutzrichtlinie.
SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere unsere Datenschutzrichtlinie und die Nutzervereinbarung.
First time at CSUN and my first time presenting. Terrible with names and faces, no official diagnosis for it, but trust me, I’m really bad so always, please feel free to approach me and (re)introduce yourself. Legally blind in one eye since birth. Early stages of glaucoma in the other.
Three projects tracked over a number of months with some variation of how defects were tracked Two were already under way and did not have accessibility oversight from the start. All were created by teams with little or no accessibility experience. In each case at least 85% of the accessibility defects created were 100% preventable with these three behaviors. It is worth noting that the “bonus” behavior (screen reader testing) was not part of the 85% calculation but would have prevented some additional errors of a similarly basic nature.
We want our developers to perform HTML validation.
We want them to do this because it is a part of WCAG: Of the four P. O. U. R. principals, one is pretty much all about following the standards and focuses on compatibility with many platforms.
We want them to do it, because HTML is “a standard”
Here we’re showing definitions of “HTML” from a bunch of different sources: W3schools, dictionary.com, Wikipedia and OxfordDictionaries.com
http://www.w3.org/standards/faq#std W3C publishes documents that define Web technologies. These documents follow a process designed to promote consensus, fairness, public accountability, and quality. At the end of this process, W3C publishes Recommendations, which are considered Web standards.
This diagram shows a number of the various participants involved in the standard; it starts with the HTML specification, and ending with the end user.
Participating in the standard, means we all promise to use it consistently. If we do, we all win. This slide shows a flow chart that starts with the HTML Specification and passes through a number of participants and products before making its way to “your users”. (One line) The HTML standard starts with the specification made by the W3C—which we can all help contribute to. Based on that standard, Browser Developers build browsers that will know what to do with the stuff in the specification. Based on the specification, Assistive Technology developers build tools know what to do with what is in the browser and the HTML specification.
(Two lines) Again, we start with the HTML standard, Based on the standard, Web Developers also know how to write HTML. Web developers use standard HTML to create documents that make up their web site / application.
(Three lines) So when an HTML document gets parsed by the browser, UI elements are displayed in a consistent way. Then when what is in the browser gets interpreted by the screen reader, it be presented in a consistent way as well. Finally, when it gets to the user (remember, they are the whole reason we’re doing all of this in the first place): It will meet all user’s every expectation and they will love you for it.
The point is, we all need this shared understanding to help make things work as expected.
The Web Accessibility Initiative’s “contract model” diagram; an image found on the “Accessible Rich Internet Applications”
This is a closer look at the pieces of an HTML document that come together in the browser and how their meaning is shared with assistive technologies through the “accessibility API”.
We want our stuff to work in the browsers our users use, not just the ones our developers use. We want our stuff to work in new browsers, not just the ones we have today. When a new device or browser comes out, as long as it follows standards we all agree to, it should work as expected.
It’s not only about the browsers though, for accessibility, we need to take it a step further: We want our stuff to work with the assistive technologies that our users use.
Browsers: Internet Explorer 11 – Microsoft Firefox – Mozilla Safari – Apple Chrome – Google Edge – Microsoft
Assistive Technologies: JAWS – Freedom Scientific VoiceOver – Apple TalkBack – Google Dragon Naturally Speaking ZoomText NVDA – NV Access
The term “BrAT” is our abbreviation for Browser and Assistive Technology combination.
Are custom elements valid HTML? We can’t consider them valid yet the validator doesn’t know anything about the custom element; so it treats it like a SPAN. If the custom element contains a block element, it breaks.
Notes: One of the worst examples I’ve ever seen of this was “title” on a custom dialog.
Too hard / takes too much time The same could be said of “real” programming languages that are less forgiving. Many DEVs still take it a step further and do unit testing on their back-end code. HTML code quality needs to be a job requirement.
Why not with HTML? Because web browsers are too forgiving.
“It works in the browser I tested it with” That’s like saying: “This house is great as long as you’re less than four feet tall” Or: “It’s a good porch as long as only one person stands on it at a time” We want our web apps to work the same on as many devices/browsers as possible WCAG says “Robust”
Many of the big-players’ pages don’t pass validation Maybe they can afford the risk
Some valid HTML doesn’t work; some invalid HTML is accessible. It is more often the case where pages work more reliably in more BrATs when using standard, valid HTML
The JS framework we’re using generates the HTML, they must know what they’re doing I hope that happens soon. We’ve heard “We can’t control the HTML that is being generated.” but have found this to be generally false.
State and dynamic content changes example: Page with a form loads: run validation Try to submit the form with no values entered and error messages are displayed: run validation Fix all the errors so all the fields look valid: run validation again.
Page at a time Several options with similar coverage Very different ways of displaying output
Site scanning Varying capabilities and maturity levels Shop carefully! Different packages might be very different fit-wise for different organization’s environments
For these tools to do their best work, make sure you’ve done HTML validation first! What, more about HTML validation? Yes!
One-third Different numbers that one hears usually vary from about one-fifth to just over one-third (~20-35%). Depends on how one measures and who one asks more than which tool is used. What this means: Type of issues (categorized WCAG Success Criteria, Techniques/Violations/etc. or customized checklists) vs the number of issues including multiple instances of the same issue
Why this comparatively small fraction is important and useful—many issues that are automatically detected are: especially tedious or time-consuming to examine in the code Items that will be a speed bump for other testing (e.g., ARIA issues)
Empathy piece—understanding how keyboard-only users navigate pages.
In addition to the keyboard, voice controls or different hardware my be used. Imagine missing navigation skip links or long menus for someone using a sip-and-puff switch.
Also remember that we’re not just doing this for people with disabilities…
While one needs to be able to perform the same task with a keyboard as one does with a mouse, some variation in how tasks are performed is often acceptable. For example, with a mouse, you can highlight some text, and drag and drop it to a new place in a document. It is an acceptable keyboard-equivalent to be able to highlight some text, cut it and then paste it to its new spot.
Other examples: In a pick-list Moving a floating panel or dialog
Learn to do each of these incrementally; don’t expect developers to learn this all at once or they will be set up to fail.
Name: You should be able tell what the purpose of the element is. The name doesn’t need to contain the role, because: Just like designers wouldn’t like it if you put the word “button” on every button…
Role Native, semantic elements all know what their role is, it sets the expectation for how the element should behave.
States / Properties Some elements include lots of important details, like “checked” or “disabled” or “has submenu” or “collapsed”
Additional descriptive information Sometimes we include helpful, instructive text to an element… such as input tips and error messages on form fields. Sometimes the AT will tell you how to interact with a specific element
Three Developer Behaviors to Eliminate 85 Percent of Accessibility Defects
HTML is a standard
HTML - Hypertext Markup Language, a standardized system
for tagging text files to achieve font, colour, graphic, and
hyperlink effects on World Wide Web pages.
Hypertext Markup Language (HTML) is
the standard markup language for creating
web pages and web applications.
HTML - HyperText Markup Language: a
set of standards, a variety of SGML,
used to tag the elements of a hypertext
document. It is the standard protocol for
formatting and displaying documents on
the World Wide Web.
HTML is the standard markup
language for creating Web
We all benefit from the standard
Web Site /
Web Browser Screen Reader
The contract model with accessibility APIs
From the Web Accessibility Initiative’s “Accessible Rich Internet Applications”
FirefoxInternet Explorer 11
Browsers and Assistive Technologies
Browser and Assistive Technology combinations (BrAT)
Sometimes, even when HTML is valid and follows the standard, users may get different
experiences with different BrATs (for example: IE11+JAWS verses Firefox + JAWS).
In our experience, good, clean, standard HTML always does better than bad code.
Browsers can fix-up bad HTML to some degree so that it looks right, but it can still be presented
incorrectly by different BrATs.
When things are a lot different between BrATs, there is often a code validation issue behind it.
Bad code example: a block breaking a block element
Bad code example: Bad parent-child relationship
Why isn’t HTML validation being done?
“It looks right in my browser”
But will that still be true after the next major browser update?
all HTML is valid”
HTML5 is very flexible,
but not that flexible.
“HTML validation is:
• too hard
• takes too much time
• plagued with false positives
“Most of the big player’s sites don’t pass”
Can you afford the same risk that they can?
“We’ve seen valid HTML
that isn’t accessible”
And we’ve seen invalid HTML that is.
“I don’t write HTML”
The JS framework we use generates the HTML,
and they must know what they’re doing.
HTML Validation Options