Skip to main content

Home/ Web Accessibility/ Group items tagged coding

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Vernon Fowler

WebAIM: Keyboard Accessibility - Tabindex - 0 views

webaim.org/...tabindex

DIG252 keyboard accessibility navigation focus html

shared by Vernon Fowler on 20 Aug 14 - No Cached
  • tabindex="0" and tabindex="-1" have special meaning and provide distinct functionality in HTML. A value of 0 indicates that the element should be placed in the default navigation order. This allows elements that are not natively focusable (such as <div>, <span>, and <p>) to receive keyboard focus. Of course one should generally use links and form controls for all interactive elements, but this does allow other elements to be focusable and trigger interaction.
  • A value of 0 indicates that the element should be placed in the default navigation order. This allows elements that are not natively focusable (such as <div>, <span>, and <p>) to receive keyboard focus.
  • A tabindex="-1" value removes the element from the default navigation flow (i.e., a user cannot tab to it), but it allows it to receive programmatic focus, meaning focus can be set to it from a link or with scripting. This can be very useful for elements that should not be tabbed to, but that may need to have focus set to them. A good example is a modal dialog window - when opened, focus should be set to the dialog so a screen reader will begin reading and the keyboard will begin navigating within the dialog. Because the dialog (probably just a <div> element) is not focusable by default, assigning it tabindex="-1" allows focus to be set to it with scripting when it is presented.
  • ...1 more annotation...
  • A value of -1 can also be useful in complex widgets and menus that utilize arrow keys or other shortcut keys to ensure that only one element within the widget is navigable with the tab key, but still allow focus to be set on other components within the widget.
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?
Vernon Fowler

Don't Use The Placeholder Attribute - Smashing Magazine - 0 views

www.smashingmagazine.com/...placeholder-attribute

inclusive input formdesign aria forms inclusivedesign hint accessibility form html

shared by Vernon Fowler on 27 Jun 18 - No Cached
  • To recap, the placeholder attribute: Can’t be automatically translated; Is oftentimes used in place of a label, locking out assistive technology; Can hide important information when content is entered; Can be too light-colored to be legible; Has limited styling options; May look like pre-filled information and be skipped over.
  • Move the placeholder content above the input, but below the label:
  • Development Here’s how to translate our designed example to code:
  • ...4 more annotations...
  • aria-describedby ensures that the p content will be described last, after the label’s content and the kind of input it is associated with.
  • By using aria-describedby to programmatically associate the input with the p element, we are creating a priority of information for screen readers that has parity with what a person browsing without a screen reader would experience.
  • The floating label effect, a close cousin to this phenomenon, oftentimes utilizes the placeholder attribute in place of a label, as well.
  • Content hidden by an on-screen keyboard. 3rd party keyboards with larger heights may have a greater risk of blocking important content.
  • Vernon Fowler on 27 Jun 18
     
    Not only argues for not using the placeholder attribute but also describes an inclusive input hint and how to code it.
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

Accessible Breadcrumb Navigation - 0 views

scottaohara.github.io/a11y_breadcrumbs

navigation accessible accessibility markup

shared by Vernon Fowler on 17 Jul 19 - No Cached
  • Being that a breadcrumb is contained within a nav element, it will be surfaced as a landmark to screen readers. Providing it an accessible name of "breadcrumb" (or whatever term may be more meaningful to your site) will help differentiate it from any other navigation landmarks in the current document, such as the primary navigation
  • using aria-label to provide an accessible name, and aria-current to indicate the currently active link
  • screen reader support for aria-current is rather good
  • ...2 more annotations...
  • Some other breadcrumb patterns remove the <a> element, or at least the href from the link. These examples retain the a href for current link, as without it, people using a screen reader and navigating by links, or via focusable content with the tab key would not come across the currently active link.
  • Breadcrumbs are useful on large websites where pages have clearly defined hierarchy.
Sandra Earl

Designing and Developing mobile web sites in the real world, part 2 - Opera Developer C... - 0 views

dev.opera.com/...d-developing-mobile-web-site-1

accessibility mobile opera best practices reading

shared by Sandra Earl on 12 Oct 10 - Cached
  • In tandem with the launch of their 3G mobile website, Siminn also launched a slightly lighter version of the same site - a 2G-optimized mobile presence to serve less powerful phones. Both sites are anchored to the same reservoir of information, but the 3G site makes less-restricted use of CSS, images, and other coding ornamentations.
  • The only distinction Siminn makes concerning the dimensionality of the user-experience is whether the device is 2G or 3G enabled. As stated before, 2G devices are sent to a slightly lighter version of the 3G site
  • This is exactly what Siminn are doing. By detecting the type of phone, they are presenting the customer with the most appropriate version of the page – either the 3G enhanced or the more basic design.
  • ...19 more annotations...
  • e chose not to try and replicate the entire Icelandair website, but rather to cleave from it four or five of its most crucial elements.
  • This page contains the only form on the mobile site. In general, forms should be avoided because form input via a mobile device can be a tricky endeavor. However, there are certain coding practices that can simplify form input. For example, if your form field should only accept numeric input, then you should make use of the -wap-input-format property of WAP CSS. The Apple iPhone will automatically set the input to numeric if the name of the input element is set to certain values - phone or zip for example.
  • Mobile users only need to be shown news items that have some inherent urgency.
  • Much like your desktop browser recognizes a mailto: link as an email address, mobile devices recognize tel: links and phone numbers.
  • Do not assume that just because the UA string is not in your enumerated list of “Accepted strings”, it is not possible to view the site.
  • This is where you build in progressive enhancements to the website experience.
  • WURFL is an open source list of known phones and their capabilities. This can be put into a database and when a mobile device visits the your site you can sniff the UA, look-up the capabilities of that device (including screen-dimensions, default browser, etc) and serve them the best possible experience.
  • The RDF vocabulary is a standard across many mobile devices. Vendors that use this approach allow mobile sites to keep up-to-date with any new devices, without having to keep their own database of device types.
  • ou can find more details about standards support in Opera Mini/Mobile 4 here: Designing with Opera Mini 4 in mind JavaScript support in Opera Mini 4
  • There are a few basic coding items to avoid in the mobile web space. Chief among these, at least for now (now being 10/2007), is client-side scripting.
  • While it's tempting to try and port that elegant bit of AJAX from your conventional web to your mobile web, you will only create headaches for yourself.
  • ome browsers do support various levels of JavaScript, but as a developer you should not expect it to work across all devices.
  • retty heavy processor hog, so continuous scripting can drain a battery fast
  • mobile browser support for stylesheets varies greatly.
  • keep things simple.
  • most mobile devices default to their own font sizes and families regardless of styling. Thus, when working on the Siminn project we made no attempt to influence font size or family. In cases where we wanted a larger font, we simply relied on the generic XHTML heading elements.
  • he inclusion of font-size=smaller in the body tag worked as a kind of global reset for font sizes in every device we tested. With this little bit of code we were able to sufficiently reduce the default font size and thus more faithfully reproduce the design that we had been tasked with coding.
  • XHTML-MP - the mobile web subset of XHTML - is fully supported on most modern devices.
  • You can't read 2 books and several articles about mobile web development and cover everything. Much of the effort is trial and error. When starting out, emulators are a good way to get a rough idea of how the site will work. It gives you some feel for the navigation, architecture and flow of the site, but the look and feel varies from the emulator to the real device. The best thing you can do is get a few real phones to test on. I'm sure between yourself, co-workers and a few friends, you can manage to test your site on a good cross-section of the phones out there. Finally, there is some help. The W3C mobile web initiative does have a checklist to see how well your site is doing and so does dev.mobi - if you take heed of these two lists, your site should give a quality experience to most customers.
Vernon Fowler

WebAIM: Alternative Text - 0 views

webaim.org/alttext

accessibility resources alt text images logos figure markup html

shared by Vernon Fowler on 27 Nov 13 - No Cached
  • Alternative text should not: be redundant (be the same as adjacent or body text). use the phrases "image of…" or "graphic of…".
  • Identifying the logo as actually being a logo (alt="Acme Company Logo") is not typically necessary.
  • If the fact that an image is a photograph or illustration, etc. is important content, it may be useful to include this in alternative text.
  • ...4 more annotations...
  • Decorative images do not present important content, are used for layout or non-informative purposes, and do not appear within a link. In almost all cases, spacer and decorative images should have null alt text (alt="").
  • In current practice on the web, many such images are given descriptive alternative text even though the images don't seem to provide useful content. Option C (alt="") would probably be most appropriate in this case because the image does not convey relevant or important content.
  • Alternative text should: presents the CONTENT and FUNCTION of the image. be succinct.
  • Decorative images still need an alt attribute, but it should be null (alt="").
Sandra Earl

Forget WYSIWYG editors - use WYSIWYM instead | 456 Berea Street - 0 views

www.456bereastreet.com/...yg_editors_use_wysiwym_instead

accessibility WYSIWYG

shared by Sandra Earl on 12 Oct 10 - Cached
  • A huge problem with almost every CMS in existence is the extremely poor quality of the code produced by their WYSIWYG editors.
  • Since visual gadgetry like WYSIWYG editors sells, every CMS has to have one.
  • That, in turn, makes it necessary for Web professionals who want to reduce the risk of clients unknowingly ruining the website’s semantics and accessibility to disable features and implement more or less advanced code cleaning procedures. It is a mess.
  • ...4 more annotations...
  • Because of the problems caused by WYSIWYG editors I have toyed with the idea of providing a much simpler interface for content editors. Markdown, BBCode, and Textile are a few possible solutions that ensure valid markup and increase the likelihood of it being semantic. The problem would be making clients accept working that way, directly editing pseudo markup. Most clients wouldn’t, so that option is ruled out.
  • But there is another kind of editor that is better suited than WYSIWYG for content-driven, client-edited sites - the WYSIWYM (What You See Is What You Mean) editor. In Visually Editing Semantics - What You See Is What You Mean, Peter Krantz mentions one such editor: WYMeditor.
  • From the WYMeditor site: Our goal is to create a XHTML strict web-based editor which will be usable on many platforms, whith the help of the Open Source Community.
  • There are a few limitations, of course. This is an early version, after all. Besides the issues Peter notes in his post about WYMeditor, here are a few more things I noticed: Table accessibility. There is no way to add elements and attributes (th, caption, scope, etc) needed for accessibility to data tables. Table resizing. It is possible to size tables by dragging handles. Doing so is reflected in the markup. That needs to be filtered out at some stage before saving the page to the database. Incorrect nesting of lists. When you create nested lists, the current list element is closed before the next level ul or ol is inserted.
Vernon Fowler

Using ARIA - 0 views

w3c.github.io/using-aria

accessibility aria

shared by Vernon Fowler on 31 Oct 18 - No Cached
  • aria-describedby with single or multiple id references
  • aria-label and aria-labelledby have similar behaviour in screen readers and the Accessibility API, but aria-label should be reserved for when there is no visible text on the page to reference or when keeping track of id values would be too difficult.
Sandra Earl

Unobtrusive and keyboard accessible connected select boxes | 456 Berea Street - 0 views

www.456bereastreet.com/...essible_connected_select_boxes

accessibility multiple select elements

shared by Sandra Earl on 12 Oct 10 - Cached
  • Any web developer who has created a reasonably complex form is probably aware of the concept of multiple select elements that are connected – choosing something from one select box either makes a new select box appear or changes the options of one that is already visible. There are usually two problems with this approach. One is that most implementations are completely dependent on JavaScript being available. Often there either is no submit button at all, or there is a submit button but without JavaScript there is no way to access the options that appear only as a result of changing the first select box. The other problem is that in some browsers, using the cursor keys to change the selected option triggers the onchange event immediately, so you can never get past the first option unless you know how to use your keyboard to display all options. I normally work around these problems by requiring users to submit the form to get the next set of options from the server. Obviously that isn’t an ideal solution either. So what other options do we have? One option that looks promising is described by Christian Heilmann in Unobtrusive connected select boxes - yet another solution approach. It involves using optgroup elements to create a two-level select box, which is then split into two separate select boxes if JavaScript is available. Neat. The solution Chris describes solves (or at least mitigates) the keyboard access problem since it doesn’t reload the page when the onchange event is triggered. And if JavaScript is unavailable, there is a single select box with option groups. The catch is that nested optgroup elements are not allowed in current versions of HTML, so this will not work when more than two connected select boxes are needed. Nested optgroup elements are allowed in the current Web Forms 2.0 Working Draft, so I guess there is a reasonable chance of that change making it into HTML 5.
Sandra Earl

The order of link pseudo-classes matters | 456 Berea Street - 0 views

www.456bereastreet.com/...of_link_pseudo-classes_matters

accessibility CSS Ordering link states

shared by Sandra Earl on 12 Oct 10 - Cached
  • Common knowledge to most who have been working with CSS for a few years, but perhaps not something that relative newcomers have come across yet: the order in which you define the different link states affects the end result. I prefer the following order: :link, :visited, :hover, :focus, :active.
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

Don't Rely on Default Browser Error Messages - Intopia - 0 views

intopia.digital/...default-browser-error-messages

accessibility forms validation HTML5

shared by Vernon Fowler on 06 Feb 19 - No Cached
  • Another issue is that the messages are temporary. As soon as you put focus on the input with mouse, keyboard or touch, the message disappears. People with cognitive impairments will find it difficult to use these, and I think anyone trying to fill in the form while they’re distracted will have trouble as well. People who rely on the keyboard for navigation (which includes both sighted users and screen reader users) will also lose these messages as they move around the form.
  • If you’re confident of your error messages, you can remove the browser validation by adding the novalidate attribute to the wrapping form element, like this: <form novalidate>...</form>
  • You can style this with CSS, using the :valid and :invalid pseudo-classes
  • ...2 more annotations...
  • Only the first error is noted with a message.
  • The rest rely on a change of border colour, which is, again, not evident to screen reader users.
  • Vernon Fowler on 06 Feb 19
     
    "When I found out the major browsers were beginning to include error validation into their support for forms, I was pretty excited. Form validation is always a fiddly part of accessibility, so I'm always looking out for ways to make it easier for developers to do properly. I read MDN's form data validation tutorial and a CSS Tricks article on client-side form validation and immediately made some test forms. Sadly, I was disappointed with the results. The default error validation in browsers is almost completely inaccessible. I was hoping we'd get default "you've forgotten to fill this in" messages that could be customised. I might have been a bit too optimistic! Validation at the browser level has many of the same issues we find at the website level."
Vernon Fowler

Customizing the Read More « WordPress Codex - 0 views

codex.wordpress.org/Customizing_the_Read_More

WEB300 wordpress accessibility links

shared by Vernon Fowler on 12 Apr 17 - No Cached
  • To customize this text, add the following code to your functions.php file.
  • If you are using a Child Theme, the above code will not work without modification if the parent theme has its own filters setting its own "more" link.
  • The following code is an example of the additional code needed to get the above code to work from a child theme of the parent theme Twenty Eleven. You will need to examine your actual parent theme's code for the correct parameters in the remove_filter() code, they must exactly match the add_filter() parameters used by the parent.
  • ...1 more annotation...
  • If you want to include the title of the post in the more text, use the_title() template tag
    • Vernon Fowler
      Vernon Fowler on 12 Apr 17
       
      Already done for you in accessibility-ready themes like twentyseventeen. If unsure, check by either looking for a screen-reader-text span inside the "Continue reading" link; or install the WP Accessibility plugin to confirm under Miscellaneous Accessibility Settings. https://wordpress.org/plugins/wp-accessibility/
  • Vernon Fowler on 12 Apr 17
     
    "Modify the Read More text when using the the_excerpt()"
Vernon Fowler

A List Apart: Articles: Now You See Me - 0 views

www.alistapart.com/...now-you-see-me

css webdesign accessibility usability content javascript class

shared by Vernon Fowler on 28 Oct 12 - No Cached
  • visibility: hidden; Element is hidden from view, but is not removed from the normal flow (i.e., it still takes up the space it normally would) Content is ignored by screen readers display: none; Element is removed from the normal flow and hidden; the space it occupied is collapsed Content is ignored by screen readers height: 0; width: 0; overflow: hidden; Element is collapsed and contents are hidden Content is ignored by screen readers
  • if you want to ensure users have access to content (even if it isn’t displayed visually in the current interface), the final option (positioning content offscreen) is really the way to go.
  • Screen readers have access to the content
  • ...6 more annotations...
  • position: absolute; left: -999em;
  • but links may “focus” oddly and negative indent may not prove long enough to fully hide content
  • limited to text and inline elements
  • Content is removed from the normal flow and shifted off the left-hand edge; the space it occupied is collapsed
    • Vernon Fowler
      Vernon Fowler on 17 Mar 13
       
      This is usually my desired effect.
  • If you don’t want your hidden content to be read by a screen reader, those defaults may work for you
  • how profoundly your choice of hiding mechanism can influence the accessibility of your content to assistive technologies like screen readers
Vernon Fowler

WebAIM: Creating Accessible Tables - Data Tables - 0 views

webaim.org/...data

tables data accessibility webdesign

shared by Vernon Fowler on 14 Jan 14 - No Cached
  • The summary attribute of the <table> tag may be used to provide a summary of a data table structure (not content). Support for summary varies, but in general, it is screen reader specific (it's not accessible to anyone else) and is not well supported. Additionally, the summary attribute is not part of the HTML5 specification. In general, if a table is so complex that it needs an explanation of how it is structured, it probably is not very accessible and should probably be simplified. For these reasons, we do not recommend the use of summary. If it is used, it must never be used for layout tables.
Vernon Fowler

WebAIM: Creating Accessible Tables - Data Tables - 0 views

webaim.org/data

creating tables data accessibility

shared by Vernon Fowler on 21 Jan 14 - No Cached
  • Another way to associate data cells and headers is to use the headers and id attributes. This method is NOT generally recommended because scope is usually sufficient for most tables, even if if the table is complex with multiple levels of headers.
  • Vernon Fowler on 21 Jan 14
     
    " scope="row""
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.
Sandra Earl

The Dutch accessibility law is awesome | 456 Berea Street - 0 views

www.456bereastreet.com/...h_accessibility_law_is_awesome

accessibility laws standards

shared by Sandra Earl on 12 Oct 10 - Cached
  • New Dutch accessibility law.
  • A few highlights of what is required: separate structure from presentation do not use deprecated markup when creating a new website, use a Strict doctype use progressive enhancement create semantic class and id values use the W3C DOM when scripting script-only links must be generated by JavaScript do not use the alt attribute to create tooltips
1 - 20 of 46 Next › Last »
Showing 20▼ items per page