<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Marco's accessibility blog &#187; WAI-ARIA</title>
	<atom:link href="http://www.marcozehe.de/tag/wai-aria/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.marcozehe.de</link>
	<description>Musings, tips and tricks about the accessible software world</description>
	<lastBuildDate>Tue, 31 Jan 2012 20:22:51 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>From WAI-ARIA to HTML5 and back&#8230;or maybe not?</title>
		<link>http://www.marcozehe.de/2011/12/05/from-wai-aria-to-html5-and-back-or-maybe-not/</link>
		<comments>http://www.marcozehe.de/2011/12/05/from-wai-aria-to-html5-and-back-or-maybe-not/#comments</comments>
		<pubDate>Mon, 05 Dec 2011 12:01:17 +0000</pubDate>
		<dc:creator>Marco</dc:creator>
				<category><![CDATA[Accessibility]]></category>
		<category><![CDATA[ARIA]]></category>
		<category><![CDATA[ConstraintValidation]]></category>
		<category><![CDATA[HTML5]]></category>
		<category><![CDATA[HTML5Forms]]></category>
		<category><![CDATA[WAI-ARIA]]></category>

		<guid isPermaLink="false">http://www.marcozehe.de/?p=291</guid>
		<description><![CDATA[Over the weekend, I gave a presentation at the German Multimediatreff. I talked about how to make things more accessible by combining HTML5 and WAI-ARIA in smart ways, using HTML5 where available and appropriate, and enhancing the user experience where &#8230; <a href="http://www.marcozehe.de/2011/12/05/from-wai-aria-to-html5-and-back-or-maybe-not/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>Over the weekend, I gave a presentation at the German <a href="http://www.multimediatreff.de"><span lang="de">Multimediatreff</span></a>. I talked about how to make things more accessible by combining HTML5 and WAI-ARIA in smart ways, using HTML5 where available and appropriate, and enhancing the user experience where HTML5 still has gaps in the implementation. This is a recap of what I showed.</p>
<h3>The premise</h3>
<p>The base for my talk is my third <a href="http://www.marcozehe.de/2008/07/16/easy-aria-tip-3-aria-invalid-and-role-alert/">easy ARIA tip</a>, where I enhanced a form with some basic local form validation to help users fill it out and avoid errors upon submission. If you are not or no longer familiar with what I did there, stop reading here and go read that post again as a recap. If you are caught up, let&#8217;s move on!</p>
<h3>From WAI-ARIA to HTML5</h3>
<p>Since then, a lot of time has passed, and we&#8217;re now much better equipped with native markup magic that HTML5 supplies us. Thankfully, Firefox and also other browsers implement most, if not all, these features now, so we can move ahead with our changes. To remind you, WAI-ARIA is there to enhance, not substitute, native markup, so whereever possible, we should use native markup when available. These changes are:</p>
<ol>
<li>Strip all JavaScript: Let&#8217;s start clean and see how far the new native markup stuff gets us!</li>
<li>Throw out all <em><code>aria-required="true"</code></em> instances and replace them with the HTML5 <em>required</em> attribute. This gives us automatic flagging of a required field not only via accessibility APIs, but also through visual indicators. Also, a required field is automatically flagged as invalid if it is empty.</li>
<li>For the field &#8216;name&#8217;, add a <em>pattern</em> attribute containing a regular expression that defines a valid name consist of some characters, one space, and some more characters. This will cover most cases, and if you&#8217;d like something more complex, consider me giving you some homework. <img src='http://www.marcozehe.de/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </li>
<li>The field &#8220;email&#8221; gets the <em>type</em> &#8220;email&#8221;, the field &#8220;website&#8221; gets the <em>type</em> &#8220;url&#8221; set. This gives us proper validation of e-mail addresses and URLs respectively right upon entry. Moreover, on mobile devices with a virtual keyboard, the most common extra keys are usually provided right out of the box.</li>
</ol>
<p>In addition, for a better error message, I am using the non-standard <em>x-moz-errormessage</em> attribute on the &#8220;name&#8221; field to tell users that the name was entered wrong rather than the standard &#8220;patterns don&#8217;t match&#8221; error message the browsers usually throw at users in the instance of them having entered a wrong value.</p>
<p>In addition, the name field contains (already in the ARIA example) a title attribute that tells users that a name must consist of at least two words.</p>
<p>Filling out this form now gives us validation upon submission. Firefox sets focus back to any invalid field it finds when users press the &#8220;submit&#8221; button. In addition, an error message is displayed describing the problem.</p>
<h3>&#8230;and back</h3>
<p>Our original example, however, was better in that it provided validation right at the point when an entry lost focus. Since this is a dynamically created alert box that is not yet a native HTML5 element, we <strong>have</strong> to resort to WAI-ARIA again to make this work the same, but using the HTML5 validation benefits. So, let&#8217;s enhance our example:</p>
<ol>
<li>Bring back the first two functions from the original ARIA version unchanged. These remove any existing alert box, and they create a new alert with the given message.</li>
<li>Adjust the function that is called in the <em>onblur</em> handler of the &#8220;name&#8221; and &#8220;email&#8221; fields (see below):
<ol>
<li>First, we have to adjust the function name to something that doesn&#8217;t clash with a reserved word. I used <code>testIfEntryIsValid</code>.</li>
<li>Now, get rid of the search string and error message parameters. These are no longer needed because the validation is done by the browser, and we simply use the HTML5 form constraints API to ask the browser for the relevant info. Also, the browser provides us with the appropriate error message, so no need to generate one ourselves here.</li>
<li>In the if clause, simply ask if the call to the checkValidity() method of the element we obtained in the line above gives us a &#8220;true&#8221; or &#8220;false&#8221; result. If true, simply remove the old alert. If false, create an alert and use the element&#8217;s validationMessage property as the message parameter. The browser will handle the rest for us.</li>
<li>Remove the lines that set <em>aria-invalid</em>. These are no longer needed, since the browser&#8217;s constraint validation will provide the invalid or valid states automatically.</li>
</ol>
</li>
<li>For the &#8220;name&#8221; and &#8220;email&#8221; fields, add back <em>onblur</em> handlers pointing to the above function and simply pass in the field&#8217;s ID.</li>
</ol>
<p>Testing this example, it shows that we&#8217;ve got our original functionality back. In addition, if we ignore the intermediate error messages, the browser&#8217;s validation mechanism will throw us back to any of the wrongly filled out fields upon a submission attempt. Note that not all browsers do this last step. Safari on the Mac, for example, will submit the form even if it contains invalid entries.</p>
<h3>In summary</h3>
<p>The new version of our form is much improved over the version we had originally. It still contains some WAI-ARIA where it makes sense, since there is no native HTML5 alert box yet. But the rest is HTML5. The JavaScript code is a bit less bloated since we don&#8217;t have to do our own validation any more, and we benefit from all the builtin constraint validation mechanisms.</p>
<p>Feedback is welcome! But before you throw things at me for my sloppy JavaScript, please keep in mind that this is just a proof of concept. If you would like to re-use this technique, I encourage you to put your best knowledge to use and put in better handling of events or such, appropriate for your web application. <img src='http://www.marcozehe.de/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>The example pages can be found (in English and German) at <a href="http://www.marco-zehe.de/examples/">this address</a>. Happy hacking!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.marcozehe.de/2011/12/05/from-wai-aria-to-html5-and-back-or-maybe-not/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Apple&#8217;s iOS 4 supports WAI-ARIA landmarks</title>
		<link>http://www.marcozehe.de/2010/06/22/apples-ios-4-supports-wai-aria-landmarks/</link>
		<comments>http://www.marcozehe.de/2010/06/22/apples-ios-4-supports-wai-aria-landmarks/#comments</comments>
		<pubDate>Tue, 22 Jun 2010 07:26:33 +0000</pubDate>
		<dc:creator>Marco</dc:creator>
				<category><![CDATA[Accessibility]]></category>
		<category><![CDATA[Apple]]></category>
		<category><![CDATA[ARIA]]></category>
		<category><![CDATA[iOS4]]></category>
		<category><![CDATA[VoiceOver]]></category>
		<category><![CDATA[WAI-ARIA]]></category>

		<guid isPermaLink="false">http://www.marcozehe.de/?p=236</guid>
		<description><![CDATA[This is, I believe, my 100th post on this blog, and I&#8217;m using it to announce that Apple&#8217;s iOS 4, released yesterday for the iPhone and iPod Touch, supports WAI-ARIA landmark in the VoiceOver screen reader. VoiceOver has had, since &#8230; <a href="http://www.marcozehe.de/2010/06/22/apples-ios-4-supports-wai-aria-landmarks/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>This is, I believe, my 100th post on this blog, and I&#8217;m using it to announce that Apple&#8217;s iOS 4, released yesterday for the iPhone and iPod Touch, supports WAI-ARIA landmark in the VoiceOver screen reader. VoiceOver has had, since its inception, a feature called the rotor. The rotor allows users to set a particula rweb element by which the one-finger-flick up and down gesture moves in mobile Safari and other apps that use a web display. This feature is now highly customizable. Not only can you enable and disable certain features (for example if you never want to navigate by graphics, you can disable it completely and it won&#8217;t show up in the rotor). But the rotor settings also include a new feature called landmarks. This rotor setting is disabled by default, but can be enabled through the Web settings sub window of the VoiceOver settings. Once enabled, and the user switches to it via the rotor gesture, navigating by WAI-ARIA landmarks on a page works very nicely. The one thing that VoiceOver does not do yet is announce the type of landmark, be it banner, main, search, complementary etc. Furthermore, the landmarks also include what is called automatic web spots in the VoiceOver on Snow Leopard for the Mac. So not only do you jump to the actually marked up landmarks, but a few more spots on a page Apple deems interesting. In my experience, these usually are quite useful spots, too, so this doesn&#8217;t harm the original landmark feature at all.</p>
<p>It is fantastic to see that WAI-ARIA is getting more and more adoption in mainstream products. VoiceOver is available on any iPhone 3G S and iPhone 4, as well as the newest generation iPod Touch models (32 and 64 GB), and the iPad. The iPad does not include the landmarks feature yet, since its iOS hasn&#8217;t been updated to version 4 yet.</p>
<h3>Further reading</h3>
<p><a href="http://www.marcozehe.de/2009/10/31/easy-aria-tip-4-landmarks/">Easy WAI-ARIA tip #4: Landmarks</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.marcozehe.de/2010/06/22/apples-ios-4-supports-wai-aria-landmarks/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>JQuery UI 1.7 released</title>
		<link>http://www.marcozehe.de/2009/03/07/jquery-ui-17-released/</link>
		<comments>http://www.marcozehe.de/2009/03/07/jquery-ui-17-released/#comments</comments>
		<pubDate>Sat, 07 Mar 2009 07:43:01 +0000</pubDate>
		<dc:creator>Marco</dc:creator>
				<category><![CDATA[Accessibility]]></category>
		<category><![CDATA[ARIA]]></category>
		<category><![CDATA[jQueryUI]]></category>
		<category><![CDATA[WAI-ARIA]]></category>

		<guid isPermaLink="false">http://www.marcozehe.de/?p=117</guid>
		<description><![CDATA[The jQuery UI team has released jQuery UI 1.7. Congrats on this release! One thing the team did not mention in the above blog post is the fact that jQuery UI 1.7 is the first version to contain WAI-ARIA enhancements, &#8230; <a href="http://www.marcozehe.de/2009/03/07/jquery-ui-17-released/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>The jQuery UI team has <a href="http://blog.jqueryui.com/2009/03/jquery-ui-17/">released jQuery UI 1.7</a>. Congrats on this release!</p>
<p>One thing the team did not mention in the above blog post is the fact that jQuery UI 1.7 is the first version to contain WAI-ARIA enhancements, making the widgets more, or at all, accessible. WOOT!</p>
<p>It&#8217;s really cool to see another big player in the JS widgets field to adopt WAI-ARIA, making modern websites more accessible the moment they just switch to this version of jQuery UI.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.marcozehe.de/2009/03/07/jquery-ui-17-released/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>

