forked from SVG-access-W3CG/new-note-draft
-
Notifications
You must be signed in to change notification settings - Fork 0
/
svgaccess.html.bak
46 lines (46 loc) · 2.22 KB
/
svgaccess.html.bak
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
<!DOCTYPE html>
<html>
<head>
<meta content="text/html; charset=windows-1252" http-equiv="content-type">
<title>New SVG accessibility note - DRAFT</title>
</head>
<body>
<h1>SVG 2 accessibility</h1>
<p>This is a stub. The idea is to add to it until it turns into a document.
That will take a lot of pull requests.</p>
<p>Editor: chaals</p>
<h2>Things that are still true</h2>
<p>i.e. since the publication of SVG 1 and the poor <a href="http://www.w3.org/TR/2000/NOTE-SVG-access-20000807">old
SVG accessibility note</a></p>
<h3>basic shapes</h3>
<p>to the extent that these can be helpful in understanding geometry, they
are still there. Unfortunately there is a tendency in practice to use a
lot of paths instead</p>
<h3><a href="http://www.w3.org/TR/SVG-access/#Re-Using">Re-usable
"components"</a></h3>
<p>the <code>use</code> element gives SVG something like what Web Components
is still trying to bring to HTML a decade-odd later.</p>
<h3>title and description</h3>
<p>The way you can use these at appropriate levels of structure is a very
nice thing.</p>
<h3>DOM</h3>
<p>Everything now uses the DOM, so it's helpful to have one.</p>
<h3><a href="http://www.w3.org/TR/SVG-access/#Fonts">Fonts</a></h3>
<p>Now enhanced to match the new technology, fonts are a much nicer thing to
do than simply adding a lot of paths to convey some text.</p>
<h2>New improvements</h2>
<h3>tabindex</h3>
<p>Being able to build a keyboard navigation map around an SVG is a great
thing. Element-wise navigation is a fallback strategy for users who don't
have a choice, but it is unlikely to be a good one if the author has done
a half-way reasonable job.</p>
<h3>aria attributes</h3>
<h2>Just different</h2>
<h3>onclick is accessible now</h3>
<p>DOMActivate was dropped because it was unnecessary, and unhelpful. Lack
of browser support and lack of author usage fed a vicious circle.</p>
<p>But onclick can be triggered by almost any mode of interaction - which
was what DOMActivate tried to enable. So we have the functionality, even
if it has a name that seems limiting.</p>
</body>
</html>