Skip to main content

Home/ Web Accessibility/ Group items tagged html

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Vernon Fowler

HTML5 Accessibility Chops: When to use an ARIA role | The Paciello Group Blog - 0 views

www.paciellogroup.com/...chops-when-to-use-an-aria-role

accessibility html5 browser

shared by Vernon Fowler on 24 Nov 12 - No Cached
  • The situation for new HTML5 elements is different and likely to remain so for some time. It will be years before New HTML5 elements get robust accessibility support implemented across browsers and platforms. This is particularly so for non interactive elements such as the new HTML5 structural elements because  accessibility APIs in general do not have defined roles for many non interactive elements. In this case it is recommended to add the appropriate ARIA roles to elements that are meant to convey meaning but are effectively meaningless due to lack of implemented accessibility support. For example, adding role=navigation to a nav element fills the gaps in support for HTML5 semantics as ARIA  is more robustly  supported by most modern browsers and assistive technology:
  • <nav role=”navigation”>
  • Authors/developers can safely assume that any element that has been around since HTML 4.0 is already accessibility supported in browsers that support accessibility. So they do not need a default implicit role added.
Vernon Fowler

10 colour contrast checking tools to improve the accessibility of your design | 456 Ber... - 3 views

www.456bereastreet.com/...e_accessibility_of_your_design

accessibility color tools webdesign css validator usability webdev validation test testing design contrast resources

shared by Vernon Fowler on 12 Oct 10 - Cached
  • online tool simulates colour blindness on an image that you upload or on a web page that you specify, while the Photoshop plugin changes the colours of the document you are working on
Sandra Earl

Make HTML messages readable in Apple Mail | 456 Berea Street - 0 views

www.456bereastreet.com/...essages_readable_in_apple_mail

accessibility font size email HTML email preferences

shared by Sandra Earl on 12 Oct 10 - Cached
  • I’ve been using this for years and can’t understand why it isn’t available in Mail’s GUI. Here’s what to do: Quit Mail.app Open Terminal.app Enter defaults write com.apple.mail PreferPlainText -bool TRUE and press enter (toggle it back by changing TRUE to FALSE) Open Mail.app View an HTML message and marvel at the readable plain text The catch is that this only works for messages that actually contain a plain text alternative, which far from all HTML email does.
  • Specify the minimum font size Apple Mail uses for HTML messages As a fallback for the messages that do not contain a plain text alternative it is useful to make sure that the text at least has a readable size: Quit Mail.app Open Terminal.app Enter defaults write com.apple.mail MinimumHTMLFontSize 13 in the Terminal window and press enter Open Mail.app View an HTML message and marvel at the readable font size You can change the font size to whatever suits your eyes. Apply both of these and you should be able to read most of the HTML email that you receive.
Vernon Fowler

How Can I Validate (X)HTML + ARIA? | The Paciello Group BlogThe Paciello Group Blog - 0 views

blog.paciellogroup.com/...how-can-i-validate-xhtml-aria

validation validator webdesign webdev testing tool

shared by Vernon Fowler on 27 Feb 14 - No Cached
  • The DTD I have used is the HTML 4.01 loose DTD with ARIA attributes added
  • A way I have developed to do this is by creating a bookmarklet that takes the innerHTML of a document (without the DOCTYPE) and adds the custom DOCTYPE to it and then sends it to the W3C validator: HTML4.01-loose+ARIA Checker (add as a favorite to try it out)
Sandra Earl

Multiple form labels and screen readers | 456 Berea Street - 0 views

www.456bereastreet.com/...form_labels_and_screen_readers

accessibility forms labels JavaScript alerts

shared by Sandra Earl on 12 Oct 10 - Cached
  • Well, it turns out you can do that. From The LABEL element in the HTML 4.01 specification: The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control. The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute. Sounds great, doesn’t it? A quick check in graphical web browsers shows that they associate multiple labels with the input field (as evidenced by the input field gaining focus when either label is clicked). But what about screen readers? It would be so useful if this would work… Unfortunately, and perhaps unsurprisingly, it looks like it doesn’t quite work as well as you’d hope. I mentioned this briefly in Use the label element to make your HTML forms accessible, but I think it’s worth bringing up again since full support for multiple labels would help us make forms more accessible to screen reader users while keeping visual designers happy. I am far from an expert user when it comes to screen readers, but I’ve done some limited testing with mostly disappointing results. Apple VoiceOver does not recognise more than one label element associated with a form control and reads only the label that comes first in the document’s source order. JAWS and Window-Eyes both do the opposite and read only the last label when an input field gains focus. The only screen reader of those that I tested that does handle multiple labels is Fire Vox. The exact results may obviously depend on user configuration and reading modes, and there may be other screen readers that get it right, but these results indicate that screen reader behaviour is too inconsistent for multiple labels to be a reliable technique.
Vernon Fowler

HTML5 accessibility - 0 views

www.html5accessibility.com

accessibility html5 browser development resources screenreaders web webstandards for:@twitter reference

shared by Vernon Fowler on 24 Nov 12 - No Cached
  • Vernon Fowler on 24 Nov 12
     
    This site is a resource to provide information about which HTML5 user interface features are accessibility supported in browsers, making them usable by people who rely upon assistive technology (AT) to use the web.
Vernon Fowler

HTML5 Accessibility Chops: section elements | The Paciello Group Blog - 0 views

www.paciellogroup.com/...ibility-chops-section-elements

accessibility html5

shared by Vernon Fowler on 24 Nov 12 - No Cached
  • The following table illustrates support and interaction features for a number of structural HTML elements. The information is based on support for these elements by the JAWS screen reader.
  • Recommended ARIA role mappings for HTML5 section elements
  • <header role=”banner”>
  • ...1 more annotation...
  • <nav role=”navigation”>
  • Vernon Fowler on 24 Nov 12
     
    "banner"
Sandra Earl

Bruce Lawson's personal site  : Proposals for changes to lists in HTML 5 - 0 views

www.brucelawson.co.uk/...als-changes-to-lists-in-html-5

accessibility HTML5 lists development standards

shared by Sandra Earl on 12 Oct 10 - Cached
  • One of the things that have long irritated me about HTML is the restriction on what elements are allowed inside lists. The specs for both HTML 4 and 5 allow only li for ul, ol, and only dt and dd are allowed inside dl definition lists. I’d like to expand that to allow h1…h6, section and div.
  • Sandra Earl on 12 Oct 10
     
    Is this what we want to do with navbars?
Sandra Earl

Tim Anderson's ITWriting - Tech writing blog » Adobe AIR: 10 reasons to love ... - 0 views

www.itwriting.com/...-it-10-reasons-to-hate-it.html

accessibility adobe air online help

shared by Sandra Earl on 12 Oct 10 - Cached
  • 3. Easy conversion of existing Flex or HTML applications. It’s the same basic runtime. In the case of HTML, AIR apps rely on WebKit, the core component in Apple’s Safari web browser.
  • 7. Rich design and multimedia. This is Flash, so ideal for highly customized UIs, animation, sound and video. Adobe is proving the point by creating a media player built with AIR. Existing Flash developers can easily use their skills to build AIR applications.
  • 4. Proprietary technology. AIR applications depend on Adobe’s runtime.
  • ...3 more annotations...
  • 6. No model for commercial components. It is not clear to me how a component vendor could sell an AIR component while protecting it from unlicensed deployment. This may limit the availability of 3rd party components, with a corresponding impact on productivity.
  • 7. Schizophrenic development model. AIR supports either Flex development, or HTML applications which run in WebKit. The ugly side of this flexibility is that there are two SDKs, even two JavaScript virtual machines with different capabilities and characteristics. While it is nice to have a way to render HTML, I am not convinced that the web application model is worth it, given the complications it causes. After all, web applications run perfectly well in the browser.
  • Lack of UI standards may lead to annoying inconsistencies between AIR applications. We are used to this on the Web; now it is coming to the desktop as well.
Vernon Fowler

html5-boilerplate/css/main.css at master · h5bp/html5-boilerplate · GitHub - 0 views

github.com/...main.css

css html5 boilerplate screen reader reading usability webdesign accessibility

shared by Vernon Fowler on 07 Oct 12 - No Cached
  • /* * Hide from both screenreaders and browsers: h5bp.com/u */.hidden {    display: none !important;    visibility: hidden;}/* * Hide only visually, but have it available for screenreaders: h5bp.com/v */.visuallyhidden {    border: 0;    clip: rect(0 0 0 0);    height: 1px;    margin: -1px;    overflow: hidden;    padding: 0;    position: absolute;    width: 1px;}/* * Extends the .visuallyhidden class to allow the element to be focusable * when navigated to via the keyboard: h5bp.com/p */.visuallyhidden.focusable:active,.visuallyhidden.focusable:focus {    clip: auto;    height: auto;    margin: 0;    overflow: visible;    position: static;    width: auto;}/* * Hide visually and from screenreaders, but maintain layout */.invisible {    visibility: hidden;}
Vernon Fowler

WebAIM: Blog - 10 Easy Accessibility Tips Anyone Can Use - 0 views

webaim.org/...10-easy-accessibility-tips

accessibility html css tips and tricks

shared by Vernon Fowler on 13 May 13 - No Cached
  • add the appropriate landmark role attribute (role="main", role="navigation", or role="search". If your site uses HTML5 <main> or <nav>, add the role to these elements.
  • Sighted keyboard users generally navigate through the links and form fields on a web page using the Tab and Shift+Tab keys on the keyboard. To help ensure they can visually identify which link or form field they have navigated to, you can add the following to your CSS file: a:focus { outline:1px solid red; background:yellow; } The colors may need to be customized to fit your site design, but they should be fairly distinctive. To take this tip one step further, you can search your CSS files for a:hover and in each instance change it to a:hover, a:focus. This will ensure that keyboard users get the same visual highlighting when they navigate to items as mouse users get when they hover over an item.
  • Vernon Fowler on 13 May 13
     
    "Today is Global Accessibility Awareness Day (GAAD). To celebrate and to help promote accessibility, here are 10 simple accessibility tips that most anyone can implement today into their web site's HTML and CSS to make it more accessible."
Vernon Fowler

Prettier Accessible Forms · An A List Apart Article - 0 views

alistapart.com/...prettyaccessibleforms

accessibility formdesign forms screenreaders

shared by Vernon Fowler on 09 Feb 19 - No Cached
  • The fieldset element allows us to group form controls into logical, related “chunks.” legend then allows us to add a caption to that fieldset, which helps users understand the context of the form controls contained within that fieldset. In some screen readers, the legend is associated with each form control within a fieldset and is read out after each tab of the keyboard, so that a particular control can always be referenced back to its legend.
  • Vernon Fowler on 09 Feb 19
     
    "The most important part of a form is the HTML we use to build it. Fortunately, HTML gives us a nice assortment of tags to build our forms in an accessible way. These are fieldset, legend, and label."
Vernon Fowler

Bruce Lawson's personal site  : The practical value of semantic HTML - 0 views

www.brucelawson.co.uk/...actical-value-of-semantic-html

accessibility html mobile navigation

shared by Vernon Fowler on 25 Feb 19 - No Cached
  • styles each header element differently depending on the value of its itemprop attribute. Using itemprop, we’re able to ensure that the author, publication date, title, and subheading are prominently featured.
  • If you plan to put things into microdata, please note that Apple, being Apple, go their own way, and don’t use a schema.org vocabulary here. Le sigh. See my article Content needs a publication date! for more. Or view source on this page to see how I’m using microdata on this article.
  • Apple WatchOS also optimises display of items wrapped in <figure> elements
  • ...4 more annotations...
  • First, choose the appropriate type attribute and element tag for your form controls. WebKit supports a variety of form control types including passwords, numeric and telephone fields, date, time, and select menus. Choosing the most relevant type attribute allows WebKit to present the most appropriate interface to handle user input.
  • unlike iOS and macOS, input methods on watchOS require full-screen interaction. Label your form controls or specify aria label or placeholder attributes to provide additional context in the status bar when a full-screen input view is presented.
  • By choosing the right semantics now, a machine that I don’t know about yet can understand my content and display it in the best way for its users.
  • Semantic HTML will give usability benefits to many users, help to future-proof your work, potentially boost your search engine results, and help people with disabilities use your site.
Vernon Fowler

HTML_CodeSniffer - 0 views

squizlabs.github.io/HTML_CodeSniffer

accessibility bookmarklet tools html WCAG wcag2

shared by Vernon Fowler on 16 Feb 14 - No Cached
  • Vernon Fowler on 16 Feb 14
     
    HTML_CodeSniffer is a client-side script that checks HTML source code and detects violations of a defined coding standard. HTML_CodeSniffer is written entirely in JavaScript, does not require any server-side processing and can be extended by developers to enforce custom coding standards by creating your own "sniffs". To get you started, HTML_CodeSniffer comes with standards that enforce the three conformance levels of the Web Content Accessibility Guidelines (WCAG) 2.0, and the web-related components of the U.S. "Section 508" legislation. An auditor interface is provided by a bookmarklet to let you try out these accessibility checks on any web page.
Vernon Fowler

WAT-C Web Accessibility Tools Consortium - 0 views

wat-c.org/index.html

accessibility webdesign tools development

shared by Vernon Fowler on 23 Feb 14 - No Cached
  • Vernon Fowler on 23 Feb 14
     
    "The Web Accessibility Tools Consortium [WAT-C] provides a collection of free tools to assist both developers and designers in the development and testing of accessible web content. The consortium is a collaboration of some of the world's leading accessibility practitioners, founded by Accessible Information Solutions (Australia), Infoaxia (Japan), The Paciello Group (USA), Wrong HTML (Japan), and Juicy Studio (UK). Our goals are to develop new tools, improve current tools and expand the range of browsers, operating systems and languages in which our tools are available."
Vernon Fowler

Bruce Lawson's personal site  : Should you use HTML5 header and footer? - 0 views

www.brucelawson.co.uk/...ou-use-html5-header-and-footer

html5 accessibility markup semantic DIG252

shared by Vernon Fowler on 22 Jun 14 - No Cached
  • Use <header>, <footer> as often as your content requires – only the main header and footer carry implicit banner and contentinfo roles. At a minimum, use them once (assuming you have a page header and footer, that is). Always use <nav> for the primary navigation. Use <main>, but only once per page.
Sandra Earl

untitled - 0 views

www.iheni.com/e-shifts-on-desktop-and-mobile

mobile accessibility reading best practices standards

shared by Sandra Earl on 12 Oct 10 - Cached
  • The upsurge in VoiceOver could be explained in part by iPhone now providing VoiceOver support; all of a sudden there is a very real reason to switch to Mac if you can use a screen reader you are familiar with on both your desktop and mobile.
  • The upsurge in VoiceOver could be explained in part by iPhone now providing VoiceOver support; all of a sudden there is a very real reason to switch to Mac if you can use a screen reader you are familiar with on both your desktop and mobile.
  • It’s good to also see the free, open source NVDA on the up. They’ve worked hard to include WAI-ARIA support and are becoming a key tool for web developers when testing.
  • ...4 more annotations...
  • We’re still faced with one massive problem with mobile access however and that’s the lack of an open, cross platform accessibility API that mobile screen readers can hook into. On desktop we have IAccessible2, MSAA and UI Automation (amongst others) but on mobile users are tied into one platform often only supporting one browser (such as iPhone, Blackberry RIM and others) so while desktop has opened up we find ourselves in a 1990’s type impasse with users left with little room to choose on mobile. Opera works well with VoiceOver but we have no way of telling if it works on the iPhone as it’s not supported. My hope is that with more users there’ll be more momentum behind breaking this stand off and opening up the market and ultimately giving users not only choice but portability between platforms.
  • It’s good to also see the free, open source NVDA on the up. They’ve worked hard to include WAI-ARIA support and are becoming a key tool for web developers when testing.
  • « Yay factor! Going global with standards and BBC Click on web accessibility Make video accessible, localised, mobile and searchable by captioning » Screen reader software usage shifts on desktop and mobile Nov 4th, 2009 by iheni WebAim released their 2009 Screen Reader Survey last week, a follow up from last years Screen Reader survey. Very good reading it makes too but of particular interest are results around screen reader choice on the desktop and increased screen reader access on mobile. For years it’s felt like screen reader users have mainly used IE on the desktop in combination with the major screen readers Jaws by Freedom Scientific and WindowEyes by GW Micro. It’s not that other platforms don’t support screen readers (we have Orca on Linux, VoiceOver on Mac) it’s just that IE seems to have dominated. As such what types of content and web technologies users can and can’t access has very much been driven by what the three software vendors Microsoft, Freedom Scientific and GW Micro have supported. This has made access to the open web a bit lopsided cutting down on choice for the end user, competition and by extension innovation. SVG is an example of a web technology that has possibly suffered by not being supported by IE and in turn by Jaws and WindowEyes. What’s interesting to see in this year’s survey is that Jaws and WindowEyes – while still the most used – have some stiff competition at snapping at their heels from open source, free screen readers (NVDA and  SAToGo ) and VoiceOver which is available with Mac: JAWS 75.2% Window Eyes 23.5% VoiceOver 14.6% System Access or System Access To Go 22.3% NVDA 25.6% While this year’s stats show little shift for Jaws and WindowEyes usage overall there is a significant leap forward for NVDA (NonVisual Desktop Access) and VoiceOver: Of the 1121 respondents, 74% use JAWS, 23% use Window-Eyes, 8% use NVDA, and 6% use VoiceOver. While several other screen readers were reported, these were the most prominently reported. The upsurge in VoiceOver could be explained in part by iPhone now providing VoiceOver support; all of a sudden there is a very real reason to switch to Mac if you can use a screen reader you are familiar with on both your desktop and mobile. This could also explain the increase of screen reader users on mobile reported this year with 53% of survey respondents with disabilities confirming they use a screen reader on a mobile device. This is up from 12% last year (although last year’s survey doesn’t distinguish disabled from non-disabled users). I wonder how much this is to do with the ‘iPhone Factor’ but also can’t help thinking that social networking has done for the mobile web what Kylie Minogue did for Agent Provocateur – everybody wants some. And for me at least 2009 feels like the year that we all sat up and paid attention to the potential of mobile for people with disabilities. We’re still faced with one massive problem with mobile access however and that’s the lack of an open, cross platform accessibility API that mobile screen readers can hook into. On desktop we have IAccessible2, MSAA and UI Automation (amongst others) but on mobile users are tied into one platform often only supporting one browser (such as iPhone, Blackberry RIM and others) so while desktop has opened up we find ourselves in a 1990’s type impasse with users left with little room to choose on mobile. Opera works well with VoiceOver but we have no way of telling if it works on the iPhone as it’s not supported. My hope is that with more users there’ll be more momentum behind breaking this stand off and opening up the market and ultimately giving users not only choice but portability between platforms.
  • We’re still faced with one massive problem with mobile access however and that’s the lack of an open, cross platform accessibility API that mobile screen readers can hook into.
  • Sandra Earl on 12 Oct 10
     
    "We're still faced with one massive problem with mobile access however and that's the lack of an open, cross platform accessibility API that mobile screen readers can hook into."
1 - 20 of 122 Next › Last »
Showing 20▼ items per page